El punto de partida
Elige el protocolo del proxy con independencia del tipo de IP de salida. Una etiqueta HTTP o SOCKS no te dice si la salida es móvil o residencial.
Empieza por el cliente y el destino
Un proxy HTTP entiende peticiones HTTP. Para un destino HTTPS, el enfoque habitual es CONNECT: el proxy establece un túnel hacia el host y el puerto de destino, y después el cliente negocia el TLS del destino a través de él. SOCKS5 negocia una conexión de retransmisión en otra capa del protocolo y define operaciones TCP y UDP.
La capacidad del protocolo no es una promesa del servicio. Un proveedor o un cliente SOCKS5 puede no implementar el comportamiento UDP que tu aplicación necesita. Confirma el soporte para la operación exacta, el método de autenticación y el puerto de destino antes de elegirlo.
Decide dónde se resuelve el DNS del destino
En la convención de URL de curl, socks5:// resuelve el destino localmente; socks5h:// envía el nombre de host del destino al proxy para que lo resuelva. Esto determina qué resolvedor ve la consulta y qué dirección devuelve. El nombre de host del propio gateway sigue teniendo que resolverlo tu cliente.
Para una prueba de QA regional, registra dónde se resuelve el DNS junto con la región de salida. De lo contrario, dos ejecuciones pueden diferir por el resolvedor y no por la red que querías comparar. Cambiar a DNS remoto es un parámetro de prueba controlado, no una garantía de que el contenido devuelto pertenezca a una región concreta.
Dibuja los dos límites de TLS
Un proxy HTTPS cifra la conexión entre el cliente y el proxy. Un destino HTTPS cifra la conexión con el destino. Son capas independientes, con validación de certificados independiente. Un gateway HTTP plano puede tunelizar un destino HTTPS, pero su propio intercambio de autenticación no queda protegido por ello por el TLS del destino.
Pregunta a tu proveedor si ofrece TLS hacia el gateway y si intercepta el TLS del destino. El tunelizado estándar y un proxy corporativo de inspección tienen requisitos de confianza distintos. Mantén la verificación activada en todas las capas TLS que estén en uso.
Usa una pequeña prueba de selección
Para una aplicación exclusivamente web, empieza por el protocolo que su cliente HTTP soporta de forma limpia. Si otra aplicación requiere específicamente SOCKS, verifica ese requisito directamente. Compara ambos contra el mismo destino permitido antes de hacer afirmaciones sobre rendimiento.
- ¿Puede el cliente autenticarse con el método del proveedor?
- ¿Puede resolver el destino en el lado de la conexión previsto?
- ¿Soporta los puertos y el transporte requeridos?
- ¿Puede tu equipo diagnosticar y monitorizar fallos en cada capa?
Antes de publicar
- Separa protocolo, tipo de salida y modo de rotación.
- Registra el comportamiento del DNS del destino.
- Verifica el TLS del gateway y el del destino cuando corresponda.
Fuentes y lecturas adicionales
Referencias técnicas usadas para esta guía. Consulta la documentación de tu versión instalada y la configuración compatible de tu proveedor.