Codex è lento ma ChatGPT sul web funziona? Diagnosi di proxy, riconnessioni e TLS

ChatGPT funziona normalmente nel browser e Google è veloce, ma Codex impiega molto a rispondere oppure mostra Reconnecting ripetutamente. In questo caso, parti dagli errori di connessione di Codex e poi decidi se cambiare nodo, modificare il proxy o attendere il modello.

Il fatto che il sito funzioni dimostra soltanto che il percorso di accesso usato dal browser è disponibile; non dimostra che le richieste di Codex passino dallo stesso proxy né che la sua connessione persistente funzioni. Se i log mostrano già tls handshake eof, una connessione reimpostata o riconnessioni consecutive, non attribuire tutto il tempo di attesa all’inferenza del modello.

Questo articolo tratta la lentezza di Codex accompagnata da anomalie di connessione. Segui quest’ordine: verifica la presenza di riconnessioni → conferma il percorso effettivo del proxy → controlla TLS e HTTPS normale → verifica poi WebSocket o la connessione in streaming.

Le valutazioni seguenti derivano da una prova reale su un Mac: tre chiamate reali di Codex sono state completate con Tailscale; il nodo AnyTLS salvato ha prodotto TLS EOF durante una ricostruzione isolata e anche Google HTTPS è fallito. La prova non ha riprodotto completamente la precedente situazione «il web è veloce, solo Codex è lento», quindi non dimostra una causa radice unica per il problema storico. Aiuta invece a decidere quale livello controllare per primo in base alle evidenze.

Codex sta ragionando o continua a riconnettersi?

Cerca prima l’errore relativo alla richiesta corrente, invece di considerare soltanto da quanto tempo l’interfaccia è ferma.

Sintomo o errore osservato	Cosa controllare per prima cosa
Reconnecting... insieme a tls handshake eof	Percorso del proxy, handshake TLS e inoltro verso la destinazione
stream disconnected before completion	Esamina l’errore specifico successivo; questa frase da sola non determina la causa
WebSocket stabilito e poi interrotto, codice di chiusura 1006	Orario e durata dell’interruzione e collegamenti intermedi
HTTP 400 che indica chiaramente che il modello richiede un aggiornamento	Versione del client; non classificarlo subito come problema di rete
Nessun errore di connessione, solo lunga attesa del risultato	Mantieni prudenza: la lentezza da sola non dimostra una disconnessione

In questa serie è stato usato lo stesso modello e lo stesso livello di ragionamento; a Codex è stato chiesto soltanto di restituire il testo fisso NETWORK_PROBE_OK:

Percorso	Risultato della chiamata reale
Tailscale, tre brevi sessioni indipendenti	Tutte completate; il processo CLI completo è durato rispettivamente 11.551, 13.945 e 14.877 secondi
HTTP CONNECT locale con uscita via Tailscale	Completato; durata totale del processo 11.634 secondi
HTTP CONNECT locale con il nodo AnyTLS salvato	Riconnessioni ripetute; nessun completamento nei 45 secondi di osservazione

La chiamata non riuscita ha generato questi log:

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

In questo caso, continuare ad aspettare non significa che il modello stia generando una risposta senza interruzioni. La richiesta sta subendo errori di connessione e nuovi tentativi; occorre controllare prima la connessione.

I tempi nella tabella includono avvio del processo, autenticazione, inferenza e trasferimento; non sono la latenza al primo token né il solo tempo di rete. I 45 secondi rappresentano il limite di arresto del programma di prova, non il tempo medio di risposta del proxy.

Perché Codex può non connettersi anche se ChatGPT sul web funziona?

Verifica separatamente la connessione effettiva di browser, applicazione desktop e CLI. Un’estensione proxy del browser, il proxy di sistema, TUN, il routing per processo e le variabili proxy del terminale possono avere ambiti diversi. Il fatto che un programma funzioni non dimostra che un altro usi lo stesso percorso.

In Clash Verge, controlla prima questi tre elementi:

1. Verifica se il registro connessioni di Clash mostra il traffico corrispondente quando Codex invia la richiesta. Impostare una variabile nel terminale non dimostra che la richiesta sia passata dal proxy.
2. Controlla che la regola applicata e l’uscita siano quelle previste. Esamina la richiesta attuale, non soltanto la schermata di selezione del nodo.
3. Confronta lo stesso contesto d’uso. Il successo della CLI non dimostra che tutte le connessioni in background dell’app desktop funzionino; una conversazione nel browser non sostituisce la prova di connessione dell’app desktop.

Durante il test reale del proxy CLI in questa serie, il registro del proxy isolato ha mostrato chatgpt.com, confermando che la richiesta ha raggiunto questo ingresso. Anche il test di controllo HTTP CONNECT ha completato una richiesta reale, segno che in questa prova il client poteva funzionare tramite quell’ingresso.

Il canale durable/app-server in errore nei log desktop, tuttavia, deve essere analizzato separatamente. Anche la documentazione OpenAI elenca richieste ed eventi SSE e WebSocket come categorie di monitoraggio distinte; non sommare il successo e l’errore di canali diversi per concludere che «la rete di Codex funziona».Categorie di eventi di telemetria della connessione Codex

Se il browser funziona ma il traffico Codex corrispondente non compare nel proxy previsto, correggi prima il percorso di quella richiesta. Cambiare nodo ripetutamente potrebbe non modificare affatto la connessione che non funziona.

Cosa controllare per primo quando Codex segnala tls handshake eof?

tls handshake eof indica che la connessione è terminata prematuramente durante l’handshake TLS. Non significa «WebSocket stabilito normalmente e poi scaduto per inattività». Verifica prima se HTTPS normale funziona tramite lo stesso proxy e poi esamina la connessione persistente dell’applicazione.

Verifica HTTPS normale tramite lo stesso proxy

Prova un semplice indirizzo HTTPS sia tramite la rete di sistema attuale sia tramite un proxy locale specificato esplicitamente. Usa la porta del client effettivamente in esecuzione; provare lo stesso URL nel browser non conferma comunque il percorso usato da Codex.

I comandi seguenti usano una porta sostituibile. 7897 è solo un esempio: sostituiscilo con la porta HTTP o mixed attuale di Clash. In questo esperimento è stata usata una porta temporanea assegnata dallo 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

Se compare subito un errore di connessione alla porta locale, verifica che Clash sia in esecuzione e che la porta sia corretta; il nodo remoto non è ancora stato testato. Se l’errore si verifica soltanto nella fase TLS, controlla il nodo e l’inoltro verso la destinazione. Anche se entrambi i comandi riescono, dimostrano solo che HTTPS breve è disponibile; devi ancora verificare Codex.

In questa serie ogni destinazione e percorso è stato provato tre volte:

Destinazione del test	Percorso Tailscale	Percorso proxy isolato con nodo salvato
Google generate_204	HTTP 204 tutte e tre le volte	curl 35 tutte e tre, senza risposta HTTP
Pagina iniziale di ChatGPT	HTTP 403 tutte e tre le volte	curl 35 tutte e tre, senza risposta HTTP
GET non autenticata all’indirizzo responses di Codex	HTTP 405 tutte e tre le volte	curl 35 tutte e tre, senza risposta HTTP

curl 35 è un errore di connessione SSL/TLS; in questa prova il messaggio era SSL_ERROR_SYSCALL.Descrizione dei codici di errore curl

Le risposte 403 e 405 non dimostrano che le funzionalità di ChatGPT o Codex siano operative; indicano soltanto che la sonda ha ricevuto una risposta HTTP. Un GET non autenticato non sostituisce nemmeno una chiamata legittima al modello. La vera verifica dell’applicazione è la richiesta nella sezione precedente che ha restituito il marcatore fisso.

Il fatto che il percorso del proxy non riesca nemmeno con HTTPS di Google è comunque sufficiente a cambiare l’ordine della diagnosi: ripristina prima l’inoltro HTTPS generale, invece di attribuire subito il problema al WebSocket di Codex.

Un nodo raggiungibile non significa che possa connetterti a OpenAI

Se l’ingresso del proxy è raggiungibile, controlla poi autenticazione, compatibilità del protocollo e inoltro verso la destinazione.

In questa prova è stato bypassato il client proxy e un socket nativo è stato associato alla scheda di rete fisica per collegarsi ai quattro ingressi IPv4 risolti del nodo. Tutte e quattro le connessioni TCP sono riuscite in circa 4–7 ms; anche gli handshake TLS con verifica del certificato sono riusciti, con un tempo totale di circa 248–553 ms.

Questo dimostra soltanto che l’ingresso è raggiungibile. Il percorso proxy comprende altri passaggi:

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

Il successo di TLS sull’ingresso e il successo di TLS verso il sito di destinazione tramite il proxy sono due verifiche diverse. Il primo non dimostra che l’autenticazione AnyTLS funzioni né che il nodo possa raggiungere Google o OpenAI.

In questa prova, fissare il dominio del nodo su uno degli IP risolti non ha fatto funzionare HTTPS di Google. Invece, la stessa implementazione dell’ingresso HTTP CONNECT locale ha ottenuto Google 204 dopo essere stata impostata su DIRECT e instradata tramite Tailscale. Questi confronti spostano l’attenzione sulla compatibilità tra protocollo del nodo e client, sullo stato di autenticazione e inoltro e sui log di uscita del server; non bastano però a individuare un’unica causa radice.

Se ottieni lo stesso risultato, il passo successivo è raccogliere gli errori di queste fasi, non concludere l’indagine perché «il ping è basso» o «la porta del server è raggiungibile».

Bisogna disattivare WebSocket se Codex continua a riconnettersi?

Distingui due elementi: il WebSocket usato dall’applicazione Codex e il protocollo di trasporto usato dal nodo proxy.

Il nodo selezionato e salvato in questa prova era AnyTLS, non un nodo VLESS/WS della configurazione. Perciò l’ipotesi «questo nodo usa WS, quindi Codex è lento» non corrisponde al tipo di nodo salvato. Il WebSocket proprio di Codex può comunque non funzionare quando attraversa quel nodo.

La necessità di esaminare WebSocket dipende dalla fase raggiunta dalla connessione:

Evidenza disponibile	Priorità dell’indagine
Anche HTTPS normale non completa l’handshake TLS	Ripristina prima la connessione e l’inoltro del proxy
HTTPS normale funziona, ma l’handshake WS fallisce	Controlla l’handshake di quella connessione, il percorso proxy e la policy di accesso
WS è stabilito e si interrompe durante l’uso o dopo l’inattività	Registra quando si interrompe e controlla il mantenimento della connessione e i passaggi intermedi

In questa prova è stata verificata una connessione persistente tramite il servizio pubblico WSS Echo di Postman: con Tailscale sono stati scambiati inizialmente cinque messaggi, poi è stato disattivato il ping periodico avviato dal client di prova, la connessione è rimasta inattiva per 90 secondi e infine sono stati scambiati altri cinque messaggi. Tutti e dieci gli echi corrispondevano. Disattivare il ping del client non significa eliminare il keepalive TCP né eventuali frame inviati dal server.Informazioni su Postman Echo

Anche un altro test di controllo HTTP CONNECT/DIRECT ha completato l’handshake WSS e l’eco. Dimostra che quell’ingresso proxy locale poteva trasportare WSS, ma non consente di generalizzare a tutti i nodi proxy; il servizio Echo pubblico non sostituisce nemmeno lo specifico endpoint di Codex.

Nei log desktop storici sono stati trovati esplicitamente 10 eventi websocket_error e 15 eventi reconnect_started, relativi al canale durable. Sono registrazioni di eventi, non 25 errori indipendenti; lo stesso errore può propagarsi in più righe di stato.

Anche il codice di chiusura 1006 indica soltanto una chiusura anomala e, da solo, non permette di stabilire chi abbia interrotto la connessione.Definizione RFC del codice di chiusura anomala WebSocket

Quindi, quando compare Reconnecting, non applicare direttamente un’impostazione per «disattivare WS». In questa prova il problema si è manifestato già nella fase TLS e non ci sono prove che modificare il timeout di inattività WebSocket sia la correzione adatta.

Tailscale può risolvere la lentezza di Codex?

Per le brevi richieste testate su questo Mac, Tailscale è stato un percorso verificato come funzionante; questo non garantisce che sia più veloce in generale. Tre chiamate reali di Codex e una prova di eco dopo 90 secondi di inattività sostengono meglio la decisione attuale di continuare a usarlo rispetto a un semplice test di velocità.

Tailscale usa WireGuard: quando è possibile connettersi direttamente, trasmette tramite UDP; altrimenti può usare un relay. Il WebSocket di Codex può funzionare nel tunnel; passare a Tailscale non equivale a disattivare WebSocket.Tipi di connessione Tailscale

Nelle 20 sonde di rilevamento Tailscale di questa prova, 17 sono riuscite e 3 sono andate in timeout; l’RTT mediano dei campioni riusciti è stato di 188 ms. Questo non equivale direttamente al tasso di perdita a lungo termine del traffico operativo, ma mostra che «funziona» non significa «senza latenza o anomalie».

Allo stesso modo, dig non dimostra la congestione della rete backbone 163. Le tre query A del dominio ChatGPT sono riuscite in 185–233 ms; misurano le query DNS e non sostituiscono TCP, TLS o richieste reali dell’applicazione. In questa prova non sono state ottenute prove di percorso sufficienti per confermare la congestione della backbone 163.

Se Codex riprende a funzionare dopo il cambio di uscita, puoi confermare che «il cambio di percorso ha modificato il risultato». Per attribuire il cambiamento a uno specifico operatore, al carico di un nodo condiviso o al protocollo proxy servono evidenze pertinenti a tale conclusione.

Come confermare che Codex si è ripreso e non che la pagina web si è appena aperta?

Verifica il client in cui si è verificato il problema, invece di tornare soltanto nel browser e aggiornare la pagina iniziale.

1. Invia una breve richiesta senza strumenti. Mantieni lo stesso modello e livello di ragionamento e verifica che arrivi una risposta completa, così da non mescolare il tempo di esecuzione degli strumenti al test di connessione.
2. Controlla la regola proxy, l’uscita e i log di errore della richiesta corrispondente. Verifica che non ci siano ancora riconnessioni; configurare un proxy non dimostra che la richiesta lo abbia attraversato.
3. Poi verifica il flusso di lavoro che in precedenza falliva. Il successo di una richiesta breve non sostituisce la verifica di attività lunghe, ripresa dopo inattività o canale desktop in background. In questa prova è stata completata solo una breve richiesta al modello; non è stato dimostrato il ripristino dei flussi lunghi.

Nell’app desktop puoi inviare: «Non leggere file né usare strumenti; rispondi soltanto NETWORK_PROBE_OK». Chi usa la CLI può provare il comando seguente: effettua una vera chiamata al modello e non è un controllo offline:

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

Verifica con la versione e le impostazioni che hanno effettivamente presentato il problema e registra errori e completamento. Non dichiarare ripristinata l’app desktop perché un’altra CLI ha risposto.

Se il client indica chiaramente che il modello richiede una versione più recente, risolvi prima la compatibilità. È successo al primo test di questa serie: la CLI indipendente 0.151.0 ha restituito HTTP 400; il nuovo test è stato eseguito con 0.164.0-alpha.11.1, incluso nell’app. Il primo risultato non è stato conteggiato come errore di rete.

Per i risultati attuali, la scelta pratica è continuare a usare Tailscale, che ha completato chiamate reali; quando indaghi questo proxy, ripristina prima HTTPS normale e poi verifica la connessione specifica di Codex. Per spiegare il precedente problema «il web funziona, solo Codex è lento», occorre ancora registrare insieme connessione e uscita quando si ripresentano quelle condizioni.

Ambito dei test: I dati dell’articolo provengono da prove locali su un Mac nelle prime ore del 27 ottobre 2026. L’esperimento proxy ha letto i parametri del nodo AnyTLS salvato e lo ha ricostruito in un processo mihomo indipendente; non ha avviato l’interfaccia/TUN originale di Clash e non ha cambiato il proxy di sistema né l’uscita Tailscale. Sebbene fosse configurato il binding alla scheda fisica, nettop non ha acquisito un’interfaccia upstream verificabile per quel processo AnyTLS; non è quindi possibile affermare che i due percorsi fisici completi siano stati verificati in modo totalmente indipendente. I risultati di CLI, canale durable desktop ed Echo pubblico sono stati registrati separatamente; dati originali, script e condizioni dettagliate sono conservati nei materiali sperimentali associati.