Codex Yavaş, ChatGPT Web Normal mi? Proxy, Yeniden Bağlanma ve TLS Hatalarını İnceleme

ChatGPT web arayüzünde normal şekilde konuşabiliyor ve Google hızlı açılıyor, ancak Codex geç yanıt veriyor ya da sürekli Reconnecting gösteriyorsa düğümü değiştirmeye, proxy ayarlarını kurcalamaya veya modeli beklemeye karar vermeden önce Codex bağlantı hatalarına bakın.

Web arayüzünün çalışması yalnızca tarayıcının mevcut erişim yolunun kullanılabildiğini gösterir. Codex isteğinin aynı proxy’den geçtiğini veya kalıcı bağlantısının sağlıklı olduğunu kanıtlamaz. Günlüklerde tls handshake eof, bağlantı sıfırlaması ya da art arda yeniden bağlanma varsa bekleme süresinin tamamı modelin düşünmesine bağlanamaz.

Bu yazı, bağlantı sorunlarının eşlik ettiği yavaş Codex durumlarını ele alıyor. İnceleme sırası şöyle: yeniden bağlanma olup olmadığını doğrulayın → kullanılan gerçek proxy yolunu doğrulayın → TLS ve sıradan HTTPS’yi kontrol edin → ardından WebSocket’i veya akış bağlantısını sınayın.

Aşağıdaki değerlendirme Mac üzerinde yapılan tek bir deneye dayanıyor: Tailscale üzerinden üç gerçek Codex çağrısı tamamlandı; kayıtlı AnyTLS düğümü yalıtılmış biçimde yeniden kurulduğunda TLS EOF verdi ve Google HTTPS de başarısız oldu. Bu deney, başlangıçtaki “web hızlı, yalnızca Codex yavaş” durumunu bütünüyle yeniden oluşturmadı; dolayısıyla önceki arızanın tek nedeni olarak görülemez. Farklı kanıtlar ortaya çıktığında önce hangi katmanın inceleneceğini belirlemeye yardımcı olur.

Codex düşünüyor mu, yoksa sürekli yeniden mi bağlanıyor?

Yalnızca arayüzün ne kadar süre beklediğine bakmayın; mevcut istekle ilişkili hatayı bulun.

Gördüğünüz belirti veya hata	Önce kontrol edilecek şey
`Reconnecting...` ve `tls handshake eof`	Proxy yolu, TLS kurulumu ve hedefe iletim
`stream disconnected before completion`	Ardından gelen somut hata; bu ifade tek başına nedeni belirlemez
WebSocket kurulduktan sonra kesilme, kapanış kodu 1006	İlgili bağlantının kapanma zamanı, süresi ve aradaki ağ yolu
Modelin daha yeni sürüm gerektirdiğini açıkça belirten HTTP 400	İstemci sürümü; bunu hemen ağ arızası saymayın
Bağlantı hatası yok, yalnızca sonuç uzun süre bekleniyor	Sonucu erteleyin; yalnızca yavaş olması ağın koptuğunu kanıtlamaz

Bu denemede aynı model ve akıl yürütme düzeyi kullanıldı; Codex’ten yalnızca sabit NETWORK_PROBE_OK metnini döndürmesi istendi:

Yol	Gerçek çağrı sonucu
Tailscale, birbirinden bağımsız üç kısa oturum	Üçü de tamamlandı; tüm CLI süreci sırasıyla 11.551, 13.945 ve 14.877 saniye sürdü
Tailscale üzerinden çıkan yerel HTTP CONNECT	Tamamlandı; tüm süreç 11.634 saniye sürdü
Kayıtlı AnyTLS düğümünü kullanan yerel HTTP CONNECT	Tekrar tekrar bağlandı; 45 saniyelik gözlem aralığında tamamlanmadı

Başarısız çağrıda şu günlükler görüldü:

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

Bu durumda beklemeye devam etmek modelin yanıt üretmeyi sürdürdüğü anlamına gelmez. İstek bağlantı hatası ve yeniden denemeler yaşıyor; önce bağlantıyı inceleyin.

Tablodaki süreler süreç başlangıcını, kimlik doğrulamayı, akıl yürütmeyi ve aktarımı kapsar; ilk token gecikmesi veya saf ağ süresi değildir. 45 saniye test programının durdurma sınırıdır, proxy’nin ortalama yanıt süresi değildir.

ChatGPT web çalışırken Codex neden yine de bağlanamayabilir?

Tarayıcı, masaüstü uygulaması ve CLI için kullanılan gerçek bağlantıyı ayrı ayrı doğrulayın. Tarayıcı proxy eklentisi, sistem proxy’si, TUN, süreç bazlı trafik yönlendirme ve terminal proxy ortam değişkenleri farklı kapsamları etkileyebilir. Bir program çalışıyor diye diğerinin de aynı yolu kullandığı sonucuna varmayın.

Clash Verge’de önce şu üç noktayı kontrol edin:

Codex isteği gönderdiği sırada Clash bağlantı günlüğünde ilgili trafik görünüyor mu? Terminal değişkenlerini ayarlamak, isteğin gerçekten proxy’den geçtiğini doğrulamaz.
Eşleşen kural ve çıkış yolu beklendiği gibi mi? Yalnızca düğüm seçme ekranına değil, mevcut isteğe bakın.
Aynı kullanım bağlamını mı karşılaştırıyorsunuz? CLI’nin çalışması masaüstü uygulamasının tüm arka plan bağlantılarının çalıştığını göstermez; web’de sohbet edebilmek de masaüstü bağlantı testinin yerini tutmaz.

Bu gerçek CLI proxy denemesinde yalıtılmış proxy’nin bağlantı günlüğünde chatgpt.com göründü; böylece isteğin bu proxy girişinden geçtiği doğrulandı. HTTP CONNECT kontrolü de gerçek isteği tamamladı ve bu denemede istemcinin söz konusu giriş üzerinden çalışabildiğini gösterdi.

Buna karşılık, masaüstü günlüğünde hata veren durable/app-server kanalı ayrıca incelenmelidir. OpenAI belgeleri SSE, WebSocket istekleri ve olayları için gözlem kategorilerini de ayrı listeler; farklı kanalların başarı ve hatalarını birleştirip “Codex ağı normal” demek doğru olmaz.Codex bağlantı telemetrisi olay kategorileri

Tarayıcı çalışıyor ancak ilgili Codex trafiği beklenen proxy’de görünmüyorsa önce o isteğin proxy yolunu düzeltin. Düğümleri tekrar tekrar değiştirmek sorunlu bağlantıyı hiç değiştirmeyebilir.

Codex `tls handshake eof` hatası veriyorsa önce neye bakılmalı?

tls handshake eof, TLS el sıkışmasının erken sonlandığını gösterir. “WebSocket normal biçimde kuruldu, sonra boşta kalma zaman aşımına uğradı” anlamına gelmez. Önce aynı proxy üzerinden normal HTTPS’nin çalışıp çalışmadığını doğrulayın, sonra uygulama katmanındaki kalıcı bağlantıyı araştırın.

Aynı proxy üzerinden sıradan HTTPS’yi sınayın

Basit bir HTTPS adresini mevcut sistem ağı üzerinden ve açıkça belirtilen yerel proxy üzerinden ayrı ayrı deneyin. Yerel proxy portu çalışan istemcinin yapılandırmasından alınmalıdır; aynı adresi yalnızca tarayıcıda denemek Codex’in kullandığı yolu doğrulamaz.

Aşağıda portu değiştirilebilen komut örnekleri var. 7897 yalnızca örnek değerdir; mevcut Clash HTTP veya mixed portuyla değiştirin. Bu deneyde betiğin ayırdığı geçici bir port kullanıldı.

# 不显式使用 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

Önce yerel porta bağlanılamadığı hatası çıkarsa Clash’in çalıştığını ve girilen portun doğru olduğunu doğrulayın; henüz uzak düğümü sınamamış olursunuz. Hata TLS aşamasında ortaya çıkarsa düğümü ve hedefe iletimi inceleyin. Her iki komutun da başarılı olması yalnızca kısa HTTPS’nin çalıştığını gösterir; Codex’i ayrıca sınayın.

Bu denemede her hedef, her yol üzerinden üç kez test edildi:

Test hedefi	Tailscale yolu	Kayıtlı düğüm üzerinden yalıtılmış proxy yolu
Google `generate_204`	Üçünde de HTTP 204	Üçünde de curl 35, HTTP yanıtı yok
ChatGPT ana sayfası	Üçünde de HTTP 403	Üçünde de curl 35, HTTP yanıtı yok
Codex responses adresine kimlik doğrulamasız GET	Üçünde de HTTP 405	Üçünde de curl 35, HTTP yanıtı yok

curl 35, SSL/TLS bağlantı hatasıdır; bu denemedeki ileti SSL_ERROR_SYSCALL idi.curl hata kodları açıklaması

Buradaki 403 ve 405 yanıtları ChatGPT ya da Codex özelliklerinin normal çalıştığını göstermez; yalnızca yoklama isteğinin HTTP yanıtı aldığını gösterir. Kimlik doğrulamasız GET, geçerli bir model çağrısının yerini hiç tutmaz. Gerçek uygulama doğrulaması önceki bölümdeki sabit işaretçili istektir.

Bununla birlikte, proxy üzerinden Google HTTPS’nin bile başarısız olması inceleme sırasını değiştirmek için yeterlidir: sorunu hemen Codex WebSocket’ine bağlamak yerine önce genel HTTPS iletimini düzeltin.

Düğüme erişebilmek OpenAI’ye bağlanabileceğiniz anlamına gelmez

Proxy girişine erişilebiliyorsa kimlik doğrulamayı, protokol uyumluluğunu ve hedefe iletimi de inceleyin.

Bu deneyde proxy istemcisi atlandı; ham socket fiziksel ağ arayüzüne bağlandı ve düğümün çözümlenen dört IPv4 girişine ayrı ayrı bağlandı. Dördünde de TCP bağlantısı yaklaşık 4–7 ms’de kuruldu; sertifika doğrulamalı TLS el sıkışmaları da başarılı oldu ve toplam süre yaklaşık 248–553 ms arasındaydı.

Bu yalnızca girişin erişilebilir olduğunu gösterir. Proxy yolunda sonraki aşamalar da vardır:

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

Girişe TLS bağlantısının başarılı olmasıyla proxy üzerinden hedef siteye TLS bağlantısının başarılı olması iki ayrı doğrulamadır. İlki AnyTLS kimlik doğrulamasının geçtiğini ya da düğümün Google veya OpenAI’ye erişebildiğini kanıtlamaz.

Bu deneyde düğüm alan adı çözümlenmiş IP’lerden birine sabitlendikten sonra da Google HTTPS başarısız oldu. Aynı yerel HTTP CONNECT girişi DIRECT olarak değiştirilip Tailscale üzerinden çıkınca Google 204 yanıtı alabildi. Bu karşılaştırmalar dikkati düğüm protokolü ile istemci uyumluluğuna, kimlik doğrulama ve iletim durumuna, ayrıca sunucu çıkış günlüklerine yöneltiyor; ancak tek bir nedeni seçmek için yeterli değil.

Siz de aynı sonucu alırsanız “ping düşük” ya da “sunucu portuna bağlanılıyor” deyip incelemeyi bitirmek yerine bu aşamalardaki hata kayıtlarını alın.

Codex sürekli Reconnecting gösteriyorsa WebSocket kapatılmalı mı?

Önce iki şeyi ayırın: Codex uygulamasının kullandığı WebSocket ve proxy düğümünün taşıma protokolü.

Bu denemede seçili ve kaydedilmiş düğüm AnyTLS idi; yapılandırmadaki VLESS/WS düğümü değildi. Bu yüzden “bu düğüm WS kullanıyor, Codex’i yavaşlatıyor” varsayımı kaydedilmiş düğüm türüyle uyuşmuyor. Ancak Codex’in kendi WebSocket’i bu düğüm üzerinden yine de başarısız olabilir.

WebSocket’i incelemek gerekip gerekmediği bağlantının hangi aşamaya geldiğine bağlıdır:

Mevcut kanıt	İnceleme odağı
Sıradan HTTPS bile TLS el sıkışmasını tamamlayamıyor	Önce proxy bağlantısını ve iletimi düzeltin
Sıradan HTTPS çalışıyor fakat WS el sıkışması başarısız	İlgili bağlantının el sıkışmasını, proxy yolunu ve erişim politikasını inceleyin
WS kurulduktan sonra kullanım sırasında veya boşta kalınca kopuyor	Kopma zamanını kaydedin; bağlantı sürdürmeyi ve aradaki ağı inceleyin

Bu denemede kalıcı bağlantı, Postman’ın herkese açık WSS Echo hizmetiyle sınandı: Tailscale üzerinden önce beş ileti alışverişi yapıldı, test istemcisinin etkin periyodik ping’i kapatıldı, 90 saniye boşta beklendi ve sonra beş ileti daha gönderildi. On echo yanıtının tamamı eşleşti. Etkin ping’i kapatmak TCP keepalive’ı ya da sunucunun gönderebileceği çerçeveleri ortadan kaldırmaz.Postman Echo hizmeti hakkında

Başka bir HTTP CONNECT/DIRECT kontrolü de WSS el sıkışmasını ve echo alışverişini tamamladı. Bu, söz konusu yerel proxy girişinin WSS taşıyabildiğini gösterir; tüm proxy düğümlerinin çalıştığı genellemesi yapılamaz. Herkese açık Echo hizmeti de Codex’in belirli uç noktasının yerini tutmaz.

Geçmiş masaüstü günlüklerinde durable kanalıyla ilgili 10 websocket_error ve 15 reconnect_started olayı açıkça bulundu. Bunlar 25 bağımsız arıza değildir; aynı hata birden çok durum günlüğüne yayılabilir.

1006 kapanış kodu yalnızca anormal kapanmayı belirtir; tek başına bağlantıyı kimin kestiğini göstermez.WebSocket anormal kapanış kodunun RFC tanımı

Bu nedenle Reconnecting göründüğünde doğrudan “WS’yi kapat” ayarını uygulamayın. Bu deneyde hata TLS aşamasında ortaya çıktı; WebSocket boşta kalma zaman aşımını değiştirmenin uygun çözüm olduğuna dair kanıt yok.

Tailscale’e geçmek Codex takılmasını çözer mi?

Bu Mac’teki kısa istek denemelerinde Tailscale çalıştığı doğrulanmış bir yol oldu; bu, her zaman daha hızlı olduğuna dair bir garanti değil. Üç gerçek Codex çağrısı ve 90 saniye boşta kalma sonrası echo, şu anda kullanmaya devam etme kararını yalnızca hız ölçümünden daha iyi destekliyor.

Tailscale WireGuard kullanır; doğrudan bağlantı mümkünse UDP ile aktarım yapar, doğrudan bağlanamazsa aktarıcı kullanabilir. Codex WebSocket’i bu tünelin içinde çalışabilir; Tailscale’e geçmek WebSocket’i kapatmak anlamına gelmez.Tailscale bağlantı türleri açıklaması

Tailscale’in 20 keşif yoklamasının 17’si başarılı, 3’ü zaman aşımına uğradı; başarılı örneklerin RTT medyanı 188 ms idi. Bu, iş trafiğinin uzun vadeli paket kaybı oranı olarak yorumlanamaz; ancak “kullanılabiliyor” olmanın “gecikme ve sorun yok” demek olmadığını gösterir.

Benzer şekilde dig, 163 omurga ağında tıkanıklık olduğunu kanıtlamaz. ChatGPT alan adının üç A sorgusu da başarılı oldu ve 185–233 ms sürdü; bunlar DNS sorgularını ölçer, TCP, TLS veya gerçek uygulama isteğinin yerini tutmaz. Bu deneyde 163 omurga ağının tıkandığını doğrulamaya yetecek yol kanıtı elde edilmedi.

Çıkış yolu değişince Codex düzelirse doğrulanabilecek şey “yol değişikliği sonucu değiştirdi” olur. Nedeni belirli bir operatöre, paylaşılan düğüm yüküne veya proxy protokolüne bağlamak için o iddiayı destekleyen kanıt gerekir.

Yalnızca web sayfası açılmadı, Codex’in düzeldiğini nasıl doğrularım?

Sorunun görüldüğü istemcide doğrulayın; tarayıcıda ana sayfayı yenilemekle yetinmeyin.

Araç çağırmayan kısa bir istek gönderin. Aynı modeli ve akıl yürütme düzeyini koruyup tam yanıt aldığınızı doğrulayın; böylece araç çalışma süresini bağlantı testine karıştırmazsınız.
İlgili isteğin proxy kuralını, çıkış yolunu ve hata kayıtlarını doğrulayın. Hâlâ yeniden bağlanma olup olmadığına bakın; proxy ayarlamak isteğin gerçekten oradan geçtiği anlamına gelmez.
Ardından daha önce başarısız olan iş akışını yeniden deneyin. Kısa isteğin başarılı olması uzun görevi, boşta kaldıktan sonra toparlanmayı veya masaüstü arka plan kanalını doğrulamaz. Bu deney yalnızca kısa model isteğini tamamladı; uzun iş akışının düzeldiğini göstermedi.

Masaüstü uygulamasında “Dosya okuma veya araç çağırma; yalnızca NETWORK_PROBE_OK yanıtını ver” yazabilirsiniz. CLI kullanıcıları aşağıdaki kısa isteği kullanabilir; çevrimdışı kontrol değil, modeli gerçekten çağırır:

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

Gerçekten sorun yaşadığınız sürüm ve ayarlarla sınayın; hataları ve tamamlanma durumunu kaydedin. Başka bir CLI yanıt veriyor diye masaüstünün düzeldiğini ilan etmeyin.

İstemci modelin daha yeni bir sürüm gerektirdiğini açıkça söylüyorsa önce sürüm uyumluluğunu çözün. Bu denemenin ilk testi de böyle bir duruma rastladı: bağımsız CLI 0.151.0 HTTP 400 döndürdü; ardından uygulamayla birlikte gelen 0.164.0-alpha.11.1 ile yeniden denendi. İlk sonuç ağ hatası sayılmadı.

Mevcut sonuca göre uygulanabilir seçim, gerçek çağrıyı tamamlamış Tailscale’i kullanmaya devam etmek; bu proxy’yi incelerken önce normal HTTPS’yi düzeltip sonra Codex’in belirli bağlantısını doğrulamaktır. Önceki “web normal, yalnızca Codex yavaş” sorununu açıklamak için aynı koşul yeniden oluştuğunda bağlantı ve çıkış yolunu eşzamanlı kaydetmek gerekir.

Test kapsamı: Bu makaledeki veriler 27 Ekim 2026 sabahının erken saatlerinde Mac üzerinde yapılan yerel testlerden geliyor. Proxy deneyi kayıtlı AnyTLS düğüm parametrelerini okuyup yalıtılmış bir mihomo sürecinde yeniden kurdu; özgün Clash GUI/TUN başlatılmadı, sistem proxy’si veya Tailscale çıkış yolu değiştirilmedi. Fiziksel ağ arayüzüne bağlama yapılandırılmış olsa da nettop, AnyTLS süreci için doğrulanabilir bir üst ağ arayüzü yakalamadı; bu nedenle iki tam fiziksel yolun bütünüyle bağımsız doğrulandığı söylenemez. CLI, masaüstü durable kanalı ve herkese açık Echo sonuçları ayrı ayrı kaydedildi; ham veriler, betikler ve ayrıntılı koşullar eşlik eden deney materyallerinde saklanıyor.