¿Codex va lento aunque ChatGPT web funciona? Diagnostica proxy, reconexiones y TLS

ChatGPT funciona con normalidad en el navegador y Google responde rápido, pero Codex tarda en contestar o muestra Reconnecting una y otra vez. En ese caso, empieza por los errores de conexión de Codex y decide después si conviene cambiar de nodo, ajustar el proxy o esperar al modelo.

Que la web funcione solo demuestra que la ruta de acceso que usa el navegador está disponible; no demuestra que las solicitudes de Codex pasen por el mismo proxy ni que su conexión persistente funcione. Si los registros ya muestran tls handshake eof, una conexión restablecida o reconexiones consecutivas, no atribuyas todo el tiempo de espera a la inferencia del modelo.

Este artículo trata la lentitud de Codex acompañada de anomalías de conexión. Sigue este orden: comprueba si hay reconexiones → confirma la ruta de proxy real → revisa TLS y HTTPS normal → valida después WebSocket o la conexión en streaming.

Las conclusiones siguientes se basan en una prueba real en un Mac: tres llamadas reales de Codex se completaron con Tailscale; el nodo AnyTLS guardado produjo TLS EOF al reconstruirlo de forma aislada y tampoco logró acceder a Google por HTTPS. La prueba no reprodujo por completo el estado anterior de «la web va rápido y solo Codex es lento», así que no demuestra la causa raíz única del incidente histórico. Sí ayuda a decidir qué capa revisar primero según las pruebas disponibles.

¿Codex está pensando o se está reconectando sin parar?

Busca primero el error de la solicitud actual; no te guíes solo por cuánto tiempo lleva inmóvil la interfaz.

Síntoma o error	Qué comprobar primero
Reconnecting... junto con tls handshake eof	Ruta del proxy, establecimiento TLS y reenvío al destino
stream disconnected before completion	Lee el error concreto que aparece después; esta frase por sí sola no determina la causa
WebSocket establecido y luego interrumpido, código de cierre 1006	Momento y duración del cierre de esa conexión y enlaces intermedios
HTTP 400 que indica explícitamente que hay que actualizar el modelo	Versión del cliente; no lo clasifiques primero como un fallo de red
No hay errores de conexión, solo una espera larga	Mantén la conclusión abierta: la lentitud por sí sola no demuestra una desconexión

En esta ronda se usó el mismo modelo y nivel de razonamiento; solo se pidió a Codex que devolviera el texto fijo NETWORK_PROBE_OK:

Ruta	Resultado de la llamada real
Tailscale, tres sesiones cortas independientes	Las tres terminaron; el proceso CLI completo tardó 11.551, 13.945 y 14.877 segundos, respectivamente
HTTP CONNECT local con salida por Tailscale	Terminó; el proceso completo tardó 11.634 segundos
HTTP CONNECT local usando el nodo AnyTLS guardado	Reconexiones repetidas; no terminó durante la ventana de observación de 45 segundos

La llamada fallida produjo estos registros:

Reconnecting... 2/5 (... tls handshake eof)
Reconnecting... 3/5 (... tls handshake eof)
Reconnecting... 4/5 (... tls handshake eof)
Reconnecting... 5/5 (... tls handshake eof)
Reconnecting... waiting for network

En ese caso, seguir esperando no significa que el modelo esté generando una respuesta de forma continua. La solicitud está sufriendo fallos de conexión y reintentos, así que primero hay que diagnosticar la conexión.

Los tiempos de la tabla incluyen el inicio del proceso, la autenticación, la inferencia y la transferencia; no son latencia hasta el primer token ni tiempo de red puro. Los 45 segundos son el límite de terminación del programa de prueba, no el tiempo medio de respuesta del proxy.

¿Por qué Codex puede no conectarse aunque ChatGPT web funcione?

Comprueba por separado la conexión real del navegador, la aplicación de escritorio y la CLI. Una extensión de proxy del navegador, el proxy del sistema, TUN, el enrutamiento por proceso y las variables de proxy del terminal pueden afectar ámbitos distintos. Que un programa funcione no permite concluir que otro use la misma ruta.

En Clash Verge, revisa primero estos tres puntos:

1. Comprueba si el registro de conexiones de Clash muestra el tráfico correspondiente cuando Codex hace la solicitud. Tener una variable configurada en el terminal no demuestra que la solicitud haya pasado por el proxy.
2. Verifica que la regla aplicada y la salida sean las esperadas. Revisa la solicitud actual, no solo la pantalla de selección del nodo.
3. Compara el mismo contexto de uso. Que la CLI funcione no demuestra que funcionen todas las conexiones en segundo plano de la aplicación de escritorio; una conversación en la web tampoco sustituye la prueba de conexión de escritorio.

En esta prueba real de proxy con CLI, el registro del proxy aislado mostró chatgpt.com, lo que confirma que la solicitud llegó a esa entrada. La prueba de control HTTP CONNECT también completó una solicitud real, señal de que en esta ronda el cliente podía funcionar a través de esa entrada.

Sin embargo, el canal durable/app-server que falla en los registros de escritorio requiere un análisis aparte. La documentación de OpenAI también clasifica por separado las solicitudes y eventos SSE y WebSocket; no combines el éxito y el fallo de canales distintos para concluir que «la red de Codex funciona».Categorías de eventos de telemetría de conexión de Codex

Si el navegador funciona pero el tráfico correspondiente de Codex no aparece en el proxy previsto, corrige primero la ruta de esa solicitud. Cambiar de nodo repetidamente podría no cambiar en absoluto la conexión que falla.

¿Qué revisar primero si Codex muestra tls handshake eof?

tls handshake eof indica que la conexión terminó antes de completar el protocolo de enlace TLS. No significa lo mismo que «WebSocket se estableció correctamente y luego expiró por inactividad». Primero comprueba si HTTPS normal funciona a través del mismo proxy; después investiga la conexión persistente de la aplicación.

Comprueba si HTTPS normal funciona por el mismo proxy

Prueba una URL HTTPS sencilla tanto por la red actual del sistema como mediante el proxy local especificado expresamente. Usa el puerto del cliente que está ejecutándose realmente; probar la misma URL en el navegador no confirma qué ruta usa Codex.

Los comandos siguientes usan un puerto sustituible. 7897 es solo un ejemplo: cámbialo por el puerto HTTP o mixed actual de Clash. En esta prueba se utilizó un puerto temporal asignado por el script.

# 不显式使用 HTTP 代理，沿当前系统路由访问。
# 如果开着 TUN 或 Tailscale，这不等于绕过它们。
curl --noproxy '*' --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

# 明确经过本地 HTTP/mixed 代理入口。
curl --proxy http://127.0.0.1:7897 --noproxy '' \
  --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

Si primero aparece un error de conexión con el puerto local, comprueba que Clash esté en ejecución y que el puerto sea correcto; todavía no has probado el nodo remoto. Si falla al llegar a TLS, revisa el nodo y el reenvío al destino. Que ambos comandos funcionen solo demuestra que HTTPS breve está disponible; aún hay que probar Codex.

En esta ronda se hicieron tres pruebas por objetivo y ruta:

Objetivo de prueba	Ruta Tailscale	Ruta del proxy aislado con nodo guardado
Google generate_204	Las tres devolvieron HTTP 204	Las tres dieron curl 35, sin respuesta HTTP
Página principal de ChatGPT	Las tres devolvieron HTTP 403	Las tres dieron curl 35, sin respuesta HTTP
GET sin autenticar a la URL de responses de Codex	Las tres devolvieron HTTP 405	Las tres dieron curl 35, sin respuesta HTTP

curl 35 es un error de establecimiento SSL/TLS; en esta ronda el mensaje fue SSL_ERROR_SYSCALL.Descripción de los códigos de error de curl

Estos 403 y 405 no demuestran que las funciones de ChatGPT o Codex estén operativas; solo indican que la sonda recibió una respuesta HTTP. Un GET sin autenticar tampoco sustituye una llamada legítima al modelo. La validación real de la aplicación es la solicitud que devolvió el marcador fijo de la sección anterior.

Aun así, que la ruta del proxy también falle con HTTPS de Google basta para cambiar el orden de diagnóstico: primero restaura el reenvío HTTPS general, en vez de atribuir el problema directamente al WebSocket de Codex.

Que el nodo acepte una conexión no significa que pueda conectarte a OpenAI

Si se puede alcanzar la entrada del proxy, comprueba a continuación la autenticación, la compatibilidad del protocolo y el reenvío al destino.

En esta ronda se evitó el cliente proxy y se vinculó un socket nativo a la tarjeta de red física para conectar con las cuatro entradas IPv4 resueltas del nodo. La conexión TCP se completó en las cuatro, en unos 4–7 ms; también se completó TLS con validación del certificado, con un tiempo total de unos 248–553 ms.

Eso solo demuestra que la entrada es accesible. La ruta del proxy incluye pasos posteriores:

本机 → 代理入口 TCP/TLS → 认证、协议处理与转发 → 目标服务

Que TLS funcione en la entrada y que TLS funcione al acceder al sitio de destino a través del proxy son dos comprobaciones distintas. La primera no demuestra que la autenticación AnyTLS funcione ni que el nodo pueda acceder a Google u OpenAI.

En esta ronda, fijar el dominio del nodo a una de las IP resueltas no hizo funcionar HTTPS de Google. En cambio, al cambiar la entrada HTTP CONNECT local de la misma implementación a DIRECT y salir por Tailscale, Google devolvió 204. Estas comparaciones orientan la atención a la compatibilidad entre protocolo del nodo y cliente, la autenticación y el estado del reenvío, y los registros de salida del servidor; no bastan para elegir una causa raíz única.

Si obtienes el mismo resultado, el siguiente paso es recopilar los errores de esas etapas, no dar por cerrada la investigación porque «el ping es bajo» o «el puerto del servidor conecta».

¿Hay que desactivar WebSocket si Codex no deja de reconectarse?

Distingue dos cosas: el WebSocket que usa la aplicación Codex y el protocolo de transporte que usa el nodo proxy.

El nodo seleccionado y guardado en esta prueba era AnyTLS, no un nodo VLESS/WS de la configuración. Por eso, la hipótesis «este nodo usa WS y por eso Codex va lento» no coincide con el tipo de nodo guardado. Aun así, el WebSocket propio de Codex podría fallar al pasar por él.

Decide si debes investigar WebSocket según la etapa alcanzada por la conexión:

Prueba disponible	Prioridad del diagnóstico
HTTPS normal tampoco completa el protocolo TLS	Repara primero la conexión y el reenvío del proxy
HTTPS normal funciona, pero falla el handshake WS	Comprueba el handshake de esa conexión, su ruta de proxy y la política de acceso
WS se establece y se corta durante el uso o tras quedar inactivo	Registra cuándo se corta y revisa el mantenimiento de la conexión y los enlaces intermedios

En esta ronda se validó una conexión persistente con el servicio público WSS Echo de Postman: con Tailscale se intercambiaron primero cinco mensajes; se desactivó el ping periódico iniciado por el cliente de prueba, se dejó inactiva la conexión 90 segundos y luego se intercambiaron otros cinco. Las diez respuestas coincidieron. Desactivar el ping del cliente no significa eliminar el keepalive TCP ni los posibles frames enviados por el servidor.Información de Postman Echo

Otra prueba de control HTTP CONNECT/DIRECT también completó el handshake WSS y el eco. Esto demuestra que esa entrada de proxy local podía transportar WSS, pero no permite generalizar que todos los nodos proxy funcionen; el servicio público Echo tampoco sustituye el endpoint específico de Codex.

En los registros históricos de escritorio se encontraron expresamente 10 eventos websocket_error y 15 eventos reconnect_started, relacionados con el canal durable. Son registros de eventos, no 25 fallos independientes; un mismo error puede propagarse a varias líneas de estado.

El código de cierre 1006 también solo indica un cierre anómalo: por sí solo no permite determinar quién interrumpió la conexión.Definición del código de cierre anómalo en el RFC de WebSocket

Por tanto, cuando aparece Reconnecting, no apliques directamente una configuración de «desactivar WS». En esta ronda el fallo ya aparecía durante TLS y no hay pruebas de que cambiar el tiempo de inactividad de WebSocket sea la solución correspondiente.

¿Tailscale puede solucionar la lentitud de Codex?

En las solicitudes cortas probadas en este Mac, Tailscale fue una ruta que ya se verificó como funcional; eso no garantiza que sea más rápida en general. Tres llamadas reales de Codex y una prueba de eco tras 90 segundos de inactividad respaldan mejor la decisión actual de seguir usándolo que una prueba de velocidad aislada.

Tailscale usa WireGuard: cuando puede conectarse directamente, transmite por UDP; si no, puede usar un relé. El WebSocket de Codex puede funcionar dentro del túnel; cambiar a Tailscale no equivale a desactivar WebSocket.Descripción de las conexiones de Tailscale

En las 20 sondas de descubrimiento de Tailscale de esta ronda, 17 tuvieron éxito y 3 expiraron; la mediana de RTT de las muestras exitosas fue de 188 ms. Esto no equivale a la tasa de pérdida de paquetes a largo plazo del tráfico de producción, pero sí muestra que «funciona» no significa «sin latencia ni anomalías».

Del mismo modo, dig no demuestra congestión en la red troncal de China Telecom 163. Las tres consultas A del dominio de ChatGPT se completaron en 185–233 ms; miden consultas DNS y no sustituyen TCP, TLS ni solicitudes reales de la aplicación. En esta ronda no se obtuvieron pruebas suficientes para confirmar congestión de la red troncal 163.

Si Codex se recupera al cambiar de salida, puedes confirmar que «cambiar la ruta cambió el resultado». Para atribuirlo además a un operador concreto, a la carga de un nodo compartido o al protocolo del proxy se necesitan pruebas que respalden esa afirmación.

¿Cómo confirmar que Codex se recuperó y no que la web solo acaba de abrir?

Valídalo en el cliente que presentó el problema; no te limites a volver al navegador y actualizar la página principal.

1. Envía una solicitud breve sin herramientas. Mantén el mismo modelo y nivel de razonamiento, y confirma que recibes una respuesta completa para no mezclar el tiempo de ejecución de herramientas con la prueba de conexión.
2. Comprueba la regla de proxy, la salida y los registros de error de esa solicitud. Verifica que no haya reconexiones; configurar un proxy no demuestra que la solicitud lo haya atravesado.
3. Prueba después el flujo de trabajo que fallaba. Una solicitud breve correcta no sustituye la validación de tareas largas, la recuperación tras inactividad ni el canal de escritorio en segundo plano. En esta ronda solo se completó una solicitud breve al modelo; no se demostró que los flujos largos se hubieran recuperado.

En la aplicación de escritorio, puedes enviar directamente: «No leas archivos ni uses herramientas; responde solo NETWORK_PROBE_OK». Quienes usan la CLI pueden probar el siguiente ejemplo; sí realiza una llamada real al modelo, no una comprobación sin conexión:

codex exec --ephemeral --skip-git-repo-check --sandbox read-only \
  '不要读取文件或调用工具，只回复 NETWORK_PROBE_OK'

Valida con la versión y los ajustes que realmente dieron problemas, y registra los errores y el resultado. No declares recuperada la aplicación de escritorio porque otra CLI haya respondido.

Si el cliente indica expresamente que el modelo necesita una versión más reciente, resuelve primero la compatibilidad de versiones. Eso ocurrió en la primera prueba de esta ronda: la CLI independiente 0.151.0 devolvió HTTP 400; después se repitió la prueba con 0.164.0-alpha.11.1, incluido en la aplicación. El primer resultado no se contó como fallo de red.

Para los resultados actuales, la opción práctica es seguir usando Tailscale, que completó llamadas reales; al investigar este proxy, primero recupera HTTPS normal y después valida la conexión específica de Codex. Para explicar el fallo anterior de «la web funcionaba, pero solo Codex era lento», aún habría que registrar simultáneamente la conexión y la salida cuando se reproduzcan esas condiciones.

Alcance de las pruebas: Los datos del artículo proceden de pruebas locales en un Mac durante la madrugada del 27 de octubre de 2026. El experimento del proxy leyó los parámetros del nodo AnyTLS guardado y lo reconstruyó en un proceso mihomo independiente; no inició la interfaz/TUN de Clash original ni cambió el proxy del sistema o la salida de Tailscale. Aunque se configuró la vinculación a la tarjeta física, nettop no capturó una interfaz ascendente verificable para ese proceso AnyTLS, por lo que no se puede afirmar que las dos rutas físicas completas se verificaran de manera totalmente independiente. Los resultados de CLI, canal durable de escritorio y Echo público se registraron por separado; los datos originales, los scripts y las condiciones detalladas se conservan en los materiales del experimento adjuntos.