Desde la elección del servidor y la región hasta la seguridad básica, instalación del proxy, autenticación y puertos, conexión del cliente, verificación y diagnóstico cuando algo falla.
Elegir servidor y región
Un proxy consume muy poca CPU y memoria, por lo que esos recursos no son el criterio principal al escoger la configuración.
No hace falta empezar con un plan potente. Los paquetes tipo servidor ligero de aplicaciones, con ancho de banda fijo y tráfico mensual incluido, suelen bastar para un proxy de uso propio con una o pocas cuentas y además son económicos. Solo cuando necesites varias instancias o requisitos concretos de ancho de banda conviene pasar a instancias de propósito general con recursos configurables por separado.
La región merece más atención que la configuración, porque la IP de salida pertenece al lugar donde está desplegado el nodo. La regla es directa: coloca el nodo en el mercado en el que trabaja la cuenta. Muchas personas eligen por velocidad de acceso. Un nodo de Hong Kong puede ser rápido desde China continental, pero si el perfil de la cuenta indica Estados Unidos y la salida aparece en Asia, esa incoherencia importa más que la velocidad. La velocidad es secundaria; la consistencia es lo primero.
Calcula el ancho de banda según el uso real. Para revisar paneles y hacer administración diaria, un ancho de banda pequeño suele bastar; para operaciones con imágenes o vídeo hace falta más; y cuantos más usuarios estén conectados al mismo tiempo, mayor será la necesidad. Si no estás seguro, empieza con el plan mínimo, observa el consumo durante un mes y ajusta después.
Completar estas tareas al encender el servidor
Elige una imagen de Linux. Estas distribuciones suelen incluir SSH de forma predeterminada, por lo que no hace falta configurar otro servicio remoto. Al comprar, establecer una contraseña personalizada en vez de usar un archivo de clave puede ahorrar un paso de conversión al configurar el proxy.
Cuando recibas el servidor, anota primero cuatro datos: IP pública, nombre de usuario (root por defecto en Linux), contraseña y puerto SSH (22 por defecto). Son los datos que introducirás en el cliente.
Después aplica la seguridad básica. Cambiar el puerto 22 predeterminado evita gran parte de los intentos de escaneo automatizado. Si el proveedor admite inicio de sesión con clave, configúralo y después puedes desactivar el acceso por contraseña. En el grupo de seguridad y en el firewall del sistema, abre solo los puertos realmente necesarios y cierra el resto. Son unos minutos de trabajo que reducen el ruido continuo de escaneos e intentos de reutilización de credenciales.
Dos formas de ofrecer el proxy
Una opción es usar directamente un túnel SSH. No hay que instalar nada en el servidor: el cliente utiliza el propio servicio SSH del servidor para reenviar el tráfico, con el puerto 22 y las credenciales del servidor. La desventaja es un rendimiento limitado; con uso prolongado o mucha concurrencia puede quedarse corto, por lo que encaja mejor para uso temporal o muy pocas cuentas.
La otra opción es instalar un servicio proxy dedicado en el servidor. Lo habitual es instalarlo con un solo comando y configurar después el método de autenticación y el puerto. Ofrece mejor rendimiento y control, y es más adecuado para uso a largo plazo. Al terminar, actívalo para que arranque automáticamente; de lo contrario, un reinicio del servidor dejará el proxy fuera de servicio.
Autenticación y puertos
Puede pensarse en tres niveles de autenticación, de menor a mayor seguridad: usuario y contraseña es lo más sencillo, pero si la contraseña se filtra se pierde el control del proxy; contraseña más lista blanca de IP de origen suele ser suficiente para el uso diario; autenticación con clave o certificado es la más sólida, aunque exige más configuración y merece la pena para cuentas que funcionarán durante mucho tiempo.
En cuanto a los puertos, no basta con configurar el puerto de escucha del servicio. También hay que abrirlo por separado en el firewall del sistema y en el grupo de seguridad del proveedor. Son controles independientes, y abrir solo uno de ellos es una causa frecuente de fallos. Además, la dirección de escucha no debe quedar vinculada únicamente al loopback local. Si funciona al probar desde el servidor pero no desde fuera, esta suele ser la causa.
Conectar el cliente y verificar
Crea un entorno nuevo en la herramienta de gestión de entornos, añade nombre y nota —incluir el propósito de la cuenta y la región objetivo ayuda mucho cuando hay muchas cuentas— y, según el tipo de proxy, introduce dirección del servidor, puerto, usuario y contraseña en la configuración del proxy. Ejecuta la prueba. Si aparece un mensaje de éxito, la ruta es accesible. Los nombres exactos de los campos dependen de la interfaz de la herramienta.
Superar la prueba es solo el primer paso. Abre el entorno y comprueba tres cosas.
Primero, que la IP de salida sea la IP pública del servidor. Abre una página que muestre la IP actual; solo si aparece la dirección del servidor el tráfico está saliendo correctamente.
Segundo, que DNS también pase por el proxy. Si DNS sigue resolviéndose localmente, la información geográfica expuesta puede no coincidir con la IP de salida y la región configurada en la cuenta pierde sentido.
Tercero, que la zona horaria y el idioma coincidan con la región de salida. Una IP de Estados Unidos con zona horaria e idioma chinos es una incoherencia evidente.
El entorno debe considerarse listo solo cuando las tres comprobaciones pasen.
Si no conecta, revisar en este orden
Si la prueba del proxy falla directamente, empieza por la conectividad: comprueba que el puerto esté abierto tanto en el grupo de seguridad como en el firewall del sistema. Después verifica que el servicio proxy esté en ejecución, especialmente si el servidor se ha reiniciado. A continuación revisa usuario y contraseña y confirma que la dirección del servidor sea correcta. Confundir la IP pública con la privada es habitual.
Si la prueba pasa pero las páginas no cargan, el problema suele estar en el entorno. Comprueba que tenga vinculado el proxy correcto y que DNS no se haya cambiado de nuevo a resolución local.
Si va lento, determina primero si el problema es la distancia o el ancho de banda. Accede al sitio objetivo directamente desde el servidor. Si el propio servidor es lento, la causa está en la región del nodo o en la ruta de red; si el servidor es rápido pero el cliente es lento, probablemente falta ancho de banda o hay demasiadas cuentas conectadas a la vez.
Cómo escalar cuando aumentan las cuentas
Usar varias cuentas en un solo servidor reduce el coste, pero todas comparten la misma IP de salida. Si la plataforma detecta relaciones por rangos de IP, todavía puede existir vinculación entre ellas. Un servidor por cuenta cuesta más, pero mantiene los entornos totalmente separados y resulta una opción más robusta para cuentas de mayor valor.
Con una herramienta de gestión de entornos como PurpleMark es más fiable asignar una salida independiente a cada cuenta que mantener una tabla manual. Con el precio habitual de los servidores ligeros, una salida por cuenta es asumible en muchos casos y también evita el trabajo posterior de rehacer cuentas por vinculación. Conviene mantener además un servidor dedicado a pruebas. No concentres todas las cuentas en una sola máquina, porque un único fallo podría afectarlas a todas de una vez.
