El error más habitual con las extensiones de proxy para el navegador es el alcance: solo gestionan el tráfico del navegador y pueden acabar usando una conexión directa cuando ninguna regla coincide. Este artículo clasifica las extensiones por uso, enumera criterios de evaluación como protocolo, autenticación, permisos y mantenimiento, y propone autopruebas para revisar la IP de salida y las fugas de WebRTC.
Las extensiones de proxy para el navegador tienen un límite que se pasa por alto con frecuencia: solo gestionan las peticiones que emite el navegador. Las actualizaciones del sistema, los clientes de escritorio y otras aplicaciones siguen usando la ruta original. Antes de elegir una herramienta, aclara exactamente qué quieres enviar por el proxy: te ahorrarás muchos diagnósticos después.
Primero, clasificarlas según tres usos
La necesidad más común es el cambio por sitio: hacer que unos cuantos dominios pasen por el proxy y que el resto siga conectándose en directo. Este caso se controla con una lista de reglas, y el valor de la extensión está en la rapidez del cambio y en la distribución por dominio.
El segundo tipo es el proxy global, en el que todo el tráfico del navegador sale por un único punto de salida. Es el más sencillo de configurar, pero el coste es inmediato: si la salida falla, el navegador se queda prácticamente sin conexión, lo que hace inestable el uso diario.
El tercer tipo va ligado a un entorno: cada perfil de navegador queda fijado a una salida y los perfiles no se afectan entre sí. Es el enfoque que se usa cuando se gestionan varias cuentas o varios proyectos en paralelo; aquí la extensión es más bien un complemento, porque la salida suele configurarse en un nivel más bajo.
Qué revisar al evaluar una extensión
El soporte de protocolos ocupa el primer lugar. Los proxys HTTP y HTTPS solo tratan TCP, mientras que SOCKS5 es más general, pero su soporte de UDP depende de la implementación, y muchas extensiones dejan pasar el UDP tal cual o lo descartan por completo. Este punto importa más adelante, porque está directamente relacionado con las fugas de WebRTC.
Conviene mirar con detalle el método de autenticación. La autenticación con usuario y contraseña es cómoda, pero las credenciales guardadas en la extensión quedan en local en texto plano o con cifrado débil, así que cualquiera que use el equipo puede leerlas; la autenticación por lista blanca de IP no guarda nada en la extensión, a cambio de tener que actualizar la lista cada vez que cambias de red.
El alcance es donde más problemas aparecen. En modo de reglas, los dominios que no coinciden con ninguna regla salen en directo por defecto, y puede que no sepas qué dominios está pidiendo realmente la página. Una vez que un sitio HTTPS ha establecido la conexión, la extensión solo ve el dominio, no la ruta concreta, así que la idea de distribuir por ruta es prácticamente inviable.
También conviene revisar el alcance de los permisos. Si una extensión de proxy además solicita permiso para leer datos de todos los sitios web, acceder a la información de las pestañas o al portapapeles, pregúntate si esos permisos tienen relación con la función que dice ofrecer. Las actualizaciones de versión del manifiesto de las extensiones también están restringiendo las interfaces disponibles, y por eso algunas extensiones antiguas se han visto obligadas a cambiar su arquitectura.
Para la actividad de mantenimiento, no mires cuántas entradas tiene el registro de cambios, sino si alguien sigue los cambios del proyecto original. Entre las extensiones de proxy, la versión de tienda de Proxy SwitchyOmega se retiró y un fork mantenido por la comunidad (como la línea ZeroOmega) asumió las adaptaciones posteriores; extensiones como FoxyProxy tienen versiones en varios navegadores. Estos son solo ejemplos neutrales; cuál encaja mejor sigue dependiendo de los puntos anteriores.
El tráfico que no cubre
Con la extensión instalada, el navegador sí pasa por el proxy, pero otros programas del mismo equipo, los servicios de actualización en segundo plano y cierto tráfico interno del navegador que no sigue la ruta de petición de la extensión pueden seguir saliendo por la máquina local. La revisión de la coherencia de red no puede limitarse al panel de la extensión. Para un aislamiento completo hay que actuar en el proxy del sistema o en un nivel superior.
Autopruebas: primero la salida, después las fugas
El primer paso es comprobar la IP de salida. Abre varias páginas que muestren la IP del visitante y su ubicación, compruébalo una vez en una ventana normal y otra en una pestaña que cumpla tus reglas, y compara si los resultados coinciden. Si una regla indica un proxy y aun así aparece tu dirección local, la regla no se aplica o el dominio no coincide. Probar varios sitios permite detectar casos en los que solo una parte de las peticiones pasa por el proxy.
El segundo paso es comprobar WebRTC. Hay páginas de prueba específicas que listan las direcciones candidatas locales y las públicas que obtiene el navegador; si entre las públicas aparece tu IP real en lugar de la salida del proxy, el tráfico UDP no pasa por el proxy y los scripts de la página todavía pueden determinar tu ubicación real en la red.
El tercer paso es comprobar el DNS. Si la ubicación del servidor de resolución DNS está muy lejos de la ubicación de la salida, algunos sitios considerarán el entorno anómalo.
El último paso es repetir la prueba en una ventana de incógnito. Muchas extensiones no están activas en modo incógnito de forma predeterminada y hay que autorizarlas manualmente en sus ajustes; olvidar este paso lleva a conclusiones completamente erróneas.
Decidir el uso después de las pruebas
Los resultados de las autopruebas son más fiables que la documentación de una extensión. Cuando la salida real, la ubicación de la resolución DNS y la exposición de WebRTC estén alineadas, decide si sigues usando la extensión o si bajas la salida a un nivel inferior. En escenarios con varios entornos en paralelo, lo mejor es asignar a cada entorno una salida propia y fija, en lugar de que varias máquinas compartan una sola salida.
