Qué hace realmente el campo Proxy de un perfil VPN de Apple
Rellenar un campo de proxy no convierte una VPN en HTTP. Hay dos conexiones implicadas y el campo solo llega a una de ellas.
Rellenar el campo Proxy de una configuración VPN de Apple parece que debería redirigir el túnel por un puerto web. No lo hace. El campo elige un intermediario a nivel de aplicación para el tráfico que una app compatible decide enviar allí. En cambio, la conexión del propio cliente VPN con su puerta de enlace la gobiernan el protocolo, el listener y el transporte que hayas configurado, y esas son decisiones distintas.
Dos conexiones, dos dueños
Cualquier configuración así implica una conexión del cliente a la puerta de enlace y otra de la aplicación al destino. La sección Proxy habla de la segunda, aunque esté en el mismo perfil que la primera.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
La referencia de ajustes de proxy de Apple enumera HTTP, HTTPS, SOCKS y la configuración automática de proxy, que describe las opciones de proxy de las aplicaciones. Ninguna de esas entradas dice nada sobre cómo llega un paquete IPsec o WireGuard a una puerta de enlace.
Aquí tienes una comprobación rápida que lo resuelve. Di el puerto y el protocolo que el cliente VPN indica en su registro. Si esa línea sigue diciendo UDP 500 o UDP 51820, el campo de proxy no ha cambiado nada en ella.
Cuándo el campo es la herramienta correcta
Hay un caso real en el que un proxy se sitúa delante del túnel, pero es una función del cliente y no un campo del perfil. El manual de OpenVPN documenta --http-proxy para conexiones TCP transportadas por un proxy HTTP CONNECT. Usarlo requiere la opción correspondiente del cliente, una puerta de enlace accesible por esa vía y un proxy que permita CONNECT al puerto en uso.
Si tu cliente expone esa opción y la red permite CONNECT al puerto, puede funcionar. Si el cliente no la expone, rellenar un proxy del sistema no tiene ningún efecto sobre el túnel.
Cuándo no cambia nada
Un perfil IKEv2 o IPsec no se convierte en un túnel HTTP porque el campo de proxy esté relleno. WireGuard tampoco, ya que su formato de configuración no tiene el concepto de proxy. Cambiar el puerto de la puerta de enlace tampoco cambia su protocolo. Y un extremo que responde a HTTPS normal no es automáticamente un listener de VPN.
La misma trampa atrapa a quien copia perfiles de la era PPTP de guías antiguas de iPad. Las opciones siguen existiendo en la interfaz; el servicio que hay detrás ya no habla ese protocolo.
Decidir qué capa hay que arreglar
Pregunta qué capa falló antes de cambiar nada. Si el cliente no puede establecer una sesión, el problema es el transporte y el campo de proxy es irrelevante. Si el túnel está activo pero una app no llega a su servidor, merece la pena inspeccionar el proxy de la aplicación. Si el túnel está activo y todas las apps fallan, los sospechosos son el enrutamiento y el DNS dentro del túnel.
Para el primer caso, pregunta al operador qué transporte o red alternativa aprobada admite. OpenVPN sobre TCP 443 existe porque algunas redes solo permiten eso, y sigue exigiendo que el servidor lo escuche.
No tomes un puerto UDP bloqueado como permiso para improvisar. Mantén intactas las comprobaciones de certificado o de identidad de la puerta de enlace en lugar de desactivarlas para que encaje el handshake.
Confirma las dos capas una a la vez
Confirma primero el túnel: mira la página de estado del cliente para ver una sesión establecida y un recuento de bytes distinto de cero. Después lee el ajuste de proxy directamente, con scutil --proxy para la configuración efectiva o networksetup -getwebproxy Wi-Fi para el valor guardado. Luego prueba una app que respete el proxy del sistema y otra que lo ignore, porque muchas apps nativas lo ignoran.
Tres resultados, tres correcciones distintas.
Si ambas capas informan de éxito y la app sigue fallando, revisa el túnel dividido, el DNS y los ajustes de red propios de la app. Esa es una tercera capa, y tampoco es el campo de proxy.