Codex Lambat, tetapi ChatGPT Web Normal? Periksa Proxy, Penyambungan Ulang, dan Kesalahan TLS

Jika ChatGPT di web bisa digunakan normal, Google cepat dibuka, tetapi Codex lama merespons atau terus menampilkan Reconnecting, periksa kesalahan koneksi Codex terlebih dahulu sebelum memutuskan mengganti node, mengubah proxy, atau menunggu model.

Web yang berfungsi normal hanya membuktikan bahwa jalur akses browser saat ini dapat digunakan. Itu tidak membuktikan permintaan Codex melewati proxy yang sama atau koneksi persisten-nya berjalan normal. Jika log sudah menunjukkan tls handshake eof, koneksi direset, atau penyambungan ulang berulang, waktu tunggu tidak bisa seluruhnya dianggap sebagai proses berpikir model.

Artikel ini membahas Codex lambat yang disertai masalah koneksi. Urutan pemeriksaan: pastikan apakah terjadi penyambungan ulang → pastikan jalur proxy yang benar-benar dipakai → periksa TLS dan HTTPS biasa → lalu verifikasi WebSocket atau koneksi streaming.

Penilaian berikut memakai satu eksperimen langsung di Mac: tiga panggilan Codex sungguhan selesai melalui Tailscale; node AnyTLS tersimpan mengalami TLS EOF saat dibangun ulang secara terisolasi, dan HTTPS ke Google pun gagal. Eksperimen ini tidak sepenuhnya mereproduksi keadaan awal “web cepat, hanya Codex lambat”, sehingga tidak boleh dianggap sebagai satu-satunya penyebab gangguan sebelumnya. Hasilnya membantu menentukan lapisan mana yang perlu diperiksa lebih dulu untuk bukti yang berbeda.

Apakah Codex sedang berpikir atau terus menyambungkan ulang?

Cari kesalahan yang terkait dengan permintaan saat ini; jangan hanya melihat berapa lama antarmuka menunggu.

Gejala atau kesalahan	Hal pertama yang perlu diperiksa
`Reconnecting...` disertai `tls handshake eof`	Jalur proxy, pembentukan TLS, dan penerusan ke tujuan
`stream disconnected before completion`	Kesalahan spesifik setelahnya; kalimat ini saja tidak menentukan penyebab
WebSocket terbentuk lalu terputus, kode penutupan 1006	Waktu dan durasi penutupan koneksi terkait serta perantara jaringan
HTTP 400 yang jelas menyatakan model memerlukan versi lebih baru	Versi klien; jangan langsung menyebutnya gangguan jaringan
Tidak ada kesalahan koneksi, hanya menunggu hasil lama	Tahan kesimpulan; lambat saja tidak membuktikan jaringan terputus

Pengujian ini menggunakan model dan tingkat penalaran yang sama, dengan permintaan agar Codex hanya mengembalikan teks tetap NETWORK_PROBE_OK:

Jalur	Hasil panggilan sungguhan
Tailscale, tiga sesi singkat independen	Semuanya selesai; seluruh proses CLI masing-masing 11.551, 13.945, dan 14.877 detik
HTTP CONNECT lokal, keluar melalui Tailscale	Selesai; seluruh proses 11.634 detik
HTTP CONNECT lokal, memakai node AnyTLS tersimpan	Terus menyambung ulang; tidak selesai selama jendela observasi 45 detik

Panggilan yang gagal mencatat log berikut:

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

Dalam situasi ini, terus menunggu tidak berarti model masih menghasilkan jawaban. Permintaan sedang mengalami kegagalan koneksi dan percobaan ulang; periksa koneksi terlebih dahulu.

Waktu dalam tabel mencakup startup proses, autentikasi, penalaran, dan transfer, bukan latensi token pertama atau waktu jaringan murni. 45 detik adalah batas penghentian program pengujian, bukan waktu respons rata-rata proxy.

Mengapa Codex masih bisa gagal terhubung ketika ChatGPT di web normal?

Pastikan koneksi aktual browser, aplikasi desktop, dan CLI secara terpisah. Ekstensi proxy browser, proxy sistem, TUN, pemisahan trafik per proses, dan variabel lingkungan proxy terminal dapat mencakup ruang lingkup yang berbeda. Jangan menyimpulkan satu program memakai jalur yang sama hanya karena program lain berfungsi.

Di Clash Verge, periksa tiga hal berikut terlebih dahulu:

Apakah catatan koneksi Clash menunjukkan trafik terkait saat Codex mengirim permintaan. Menyetel variabel di terminal belum membuktikan permintaan benar-benar melewati proxy.
Apakah aturan yang cocok dan jalur keluar sesuai harapan. Periksa permintaan saat ini, bukan hanya layar pemilihan node.
Apakah yang dibandingkan adalah konteks penggunaan yang sama. CLI yang berhasil tidak berarti semua koneksi latar belakang aplikasi desktop berhasil; web yang dapat diajak bicara juga tidak menggantikan pemeriksaan koneksi aplikasi desktop.

Dalam pengujian proxy CLI sungguhan ini, catatan koneksi proxy terisolasi menampilkan chatgpt.com, sehingga permintaan dipastikan masuk ke titik masuk proxy tersebut. Pembanding HTTP CONNECT juga menyelesaikan permintaan sungguhan, menandakan klien dapat bekerja melalui titik masuk itu dalam eksperimen ini.

Namun, kanal durable/app-server yang dilaporkan bermasalah dalam log desktop perlu dianalisis tersendiri. Dokumentasi OpenAI juga memisahkan kategori pengamatan untuk SSE, permintaan WebSocket, dan peristiwa; keberhasilan dan kegagalan kanal yang berbeda tidak boleh digabung menjadi kesimpulan “jaringan Codex normal”.Kategori peristiwa telemetri koneksi Codex

Jika browser normal tetapi trafik Codex terkait tidak muncul di proxy yang diharapkan, utamakan memperbaiki jalur proxy untuk permintaan tersebut. Mengganti node berulang kali mungkin sama sekali tidak mengubah koneksi yang bermasalah.

Apa yang harus diperiksa lebih dulu saat Codex melaporkan `tls handshake eof`?

tls handshake eof menunjukkan proses handshake TLS berakhir lebih awal. Ini bukan sinonim dari “WebSocket berhasil dibentuk lalu mengalami batas waktu idle”. Pastikan HTTPS biasa dapat melewati proxy yang sama terlebih dahulu, baru selidiki koneksi persisten di lapisan aplikasi.

Periksa HTTPS biasa melalui proxy yang sama

Uji alamat HTTPS sederhana melalui jaringan sistem saat ini dan melalui proxy lokal yang ditentukan secara eksplisit. Port proxy lokal harus sesuai dengan klien yang sedang berjalan; hanya menguji alamat yang sama di browser tetap tidak membuktikan jalur yang digunakan Codex.

Berikut contoh perintah dengan port yang dapat diganti. 7897 hanya nilai contoh; ubah ke port HTTP atau mixed Clash yang sedang dipakai. Eksperimen ini menggunakan port sementara yang dialokasikan oleh skrip.

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

Jika awalnya muncul kesalahan bahwa port lokal tidak dapat dihubungi, pastikan Clash berjalan dan port yang dimasukkan benar; node jarak jauh belum diuji. Jika baru gagal pada tahap TLS, periksa node dan penerusan ke tujuan. Kedua perintah yang berhasil hanya menunjukkan HTTPS singkat dapat digunakan; Codex tetap harus diuji.

Eksperimen ini menguji setiap tujuan melalui setiap jalur tiga kali:

Tujuan pengujian	Jalur Tailscale	Jalur proxy terisolasi melalui node tersimpan
Google `generate_204`	Ketiganya HTTP 204	Ketiganya curl 35, tanpa respons HTTP
Halaman utama ChatGPT	Ketiganya HTTP 403	Ketiganya curl 35, tanpa respons HTTP
GET tanpa autentikasi ke alamat Codex responses	Ketiganya HTTP 405	Ketiganya curl 35, tanpa respons HTTP

curl 35 adalah kesalahan koneksi SSL/TLS; pesan kali ini adalah SSL_ERROR_SYSCALL.Penjelasan kode kesalahan curl

HTTP 403 dan 405 di sini tidak membuktikan fungsi ChatGPT atau Codex berjalan normal; keduanya hanya berarti probe menerima respons HTTP. GET tanpa autentikasi juga tidak dapat menggantikan panggilan model yang sah. Verifikasi aplikasi yang sebenarnya adalah permintaan dengan penanda tetap di bagian sebelumnya.

Namun, kegagalan HTTPS melalui proxy bahkan ke Google cukup untuk mengubah urutan pemeriksaan: pulihkan penerusan HTTPS umum terlebih dahulu, alih-alih langsung menyimpulkan WebSocket Codex penyebabnya.

Node yang dapat dijangkau belum tentu dapat menghubungkan Anda ke OpenAI

Jika titik masuk proxy dapat dijangkau, periksa autentikasi, kompatibilitas protokol, dan status penerusan ke tujuan.

Dalam eksperimen ini, klien proxy dilewati; socket asli diikat ke antarmuka jaringan fisik, lalu dihubungkan ke empat alamat IPv4 hasil resolusi node. Koneksi TCP ke keempat alamat berhasil dalam sekitar 4–7 ms; handshake TLS dengan verifikasi sertifikat juga berhasil, dengan total waktu sekitar 248–553 ms.

Ini hanya menunjukkan titik masuk dapat dijangkau. Jalur proxy memiliki tahap lanjutan:

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

TLS yang berhasil ke titik masuk dan TLS yang berhasil ke situs tujuan melalui proxy adalah dua verifikasi berbeda. Yang pertama tidak membuktikan autentikasi AnyTLS berhasil atau node dapat mengakses Google maupun OpenAI.

Dalam eksperimen ini, HTTPS Google tetap gagal setelah domain node dipatok ke salah satu IP yang telah diresolusikan. Pembanding HTTP CONNECT lokal yang sama diubah ke DIRECT dan keluar melalui Tailscale berhasil menerima Google 204. Perbandingan ini mengarahkan perhatian ke kompatibilitas protokol node dengan klien, autentikasi dan status penerusan, serta catatan trafik keluar di server, tetapi belum cukup untuk memilih satu penyebab pasti.

Jika hasil Anda sama, langkah berikutnya adalah mengambil catatan kesalahan dari tahap-tahap ini, bukan mengakhiri pemeriksaan dengan “ping rendah” atau “port server dapat dihubungi”.

Codex terus Reconnecting, apakah WebSocket harus dimatikan?

Pertama, bedakan dua hal: WebSocket yang digunakan aplikasi Codex dan protokol transport node proxy.

Node terpilih yang tersimpan dalam eksperimen ini adalah AnyTLS, bukan node VLESS/WS di konfigurasi. Jadi dugaan “node ini memakai WS sehingga Codex lambat” tidak cocok dengan jenis node tersimpan. Namun WebSocket milik Codex sendiri tetap mungkin gagal saat melewati node tersebut.

Perlu tidaknya memeriksa WebSocket bergantung pada tahap koneksi yang telah dicapai:

Bukti yang tersedia	Fokus pemeriksaan
HTTPS biasa pun gagal melakukan handshake TLS	Perbaiki pembentukan koneksi proxy dan penerusan terlebih dahulu
HTTPS biasa normal, tetapi handshake WS gagal	Periksa handshake, jalur proxy, dan kebijakan akses untuk koneksi terkait
WS terbentuk lalu terputus saat digunakan atau setelah idle	Catat kapan putus; periksa pemeliharaan koneksi dan jaringan perantara

Eksperimen ini memverifikasi koneksi persisten lewat layanan WSS Echo publik Postman: melalui Tailscale, lima pesan dipertukarkan, ping berkala aktif dari klien pengujian dimatikan, koneksi dibiarkan idle selama 90 detik, lalu lima pesan lagi dipertukarkan. Kesepuluh balasan echo cocok. Mematikan ping aktif tidak berarti TCP keepalive atau frame yang mungkin dikirim server ikut dihilangkan.Keterangan layanan Postman Echo

Pembanding HTTP CONNECT/DIRECT lainnya juga menyelesaikan handshake WSS dan echo. Ini menunjukkan titik masuk proxy lokal tersebut dapat membawa WSS; hasilnya tidak berlaku otomatis untuk semua node proxy. Layanan Echo publik juga bukan pengganti endpoint Codex yang sebenarnya.

Log desktop historis secara jelas menunjukkan 10 peristiwa websocket_error dan 15 peristiwa reconnect_started yang melibatkan kanal durable. Ini adalah catatan peristiwa, bukan 25 kegagalan terpisah; satu kesalahan dapat menyebar ke banyak catatan status.

Kode penutupan 1006 hanya berarti penutupan abnormal; kode itu saja tidak menunjukkan pihak mana yang memutus koneksi.Definisi RFC untuk kode penutupan WebSocket abnormal

Karena itu, saat Reconnecting muncul, jangan langsung menerapkan konfigurasi “matikan WS”. Kegagalan dalam eksperimen ini sudah muncul pada tahap TLS; belum ada bukti bahwa mengubah batas waktu idle WebSocket merupakan perbaikan yang sesuai.

Apakah berpindah ke Tailscale akan mengatasi Codex yang tersendat?

Untuk permintaan singkat pada pengujian Mac ini, Tailscale adalah jalur yang sudah terbukti berfungsi; ini bukan jaminan bahwa Tailscale selalu lebih cepat. Tiga panggilan Codex nyata dan echo setelah idle 90 detik lebih mendukung pilihan apakah tetap menggunakannya sekarang dibanding sekadar tes kecepatan.

Tailscale menggunakan WireGuard, dapat mengirim lewat UDP saat koneksi langsung memungkinkan, dan mungkin memakai relay jika koneksi langsung tidak tersedia. WebSocket Codex dapat berjalan di dalam terowongannya; beralih ke Tailscale tidak sama dengan menonaktifkan WebSocket.Penjelasan jenis koneksi Tailscale

Dari 20 probe penemuan Tailscale, 17 berhasil dan 3 timeout; median RTT dari sampel yang berhasil adalah 188 ms. Ini tidak dapat dianggap sebagai tingkat kehilangan paket jangka panjang untuk trafik bisnis, tetapi menunjukkan bahwa “bisa dipakai” tidak berarti “tanpa latensi atau gangguan”.

Demikian pula, dig tidak membuktikan kemacetan backbone 163. Tiga kueri A domain ChatGPT berhasil, dengan waktu 185–233 ms; kueri tersebut mengukur DNS dan tidak menggantikan TCP, TLS, maupun permintaan aplikasi nyata. Eksperimen ini tidak memperoleh bukti jalur yang cukup untuk memastikan backbone 163 mengalami kemacetan.

Jika Codex pulih setelah jalur keluar diganti, yang dapat dipastikan adalah “perubahan jalur mengubah hasil”. Untuk mengaitkan penyebab lebih jauh dengan operator tertentu, beban node bersama, atau protokol proxy, diperlukan bukti yang sesuai dengan dugaan tersebut.

Bagaimana memastikan Codex sudah pulih, bukan hanya kebetulan halaman web terbuka?

Verifikasi di klien yang mengalami masalah, bukan sekadar kembali menyegarkan beranda di browser.

Kirim permintaan singkat tanpa memanggil alat. Pertahankan model dan tingkat penalaran yang sama; pastikan hasil lengkap diterima agar waktu eksekusi alat tidak tercampur ke pengujian koneksi.
Pastikan aturan proxy, jalur keluar, dan catatan kesalahan untuk permintaan terkait. Periksa apakah masih ada penyambungan ulang; pengaturan proxy tidak membuktikan permintaan benar-benar melewatinya.
Lalu uji lagi alur kerja yang sebelumnya gagal. Permintaan singkat yang berhasil tidak menggantikan verifikasi tugas panjang, pemulihan setelah idle, atau kanal latar belakang desktop. Eksperimen ini hanya menyelesaikan permintaan model singkat; belum membuktikan alur kerja panjang pulih.

Di aplikasi desktop, kirim: “Jangan membaca file atau memanggil alat, balas hanya NETWORK_PROBE_OK.” Pengguna CLI dapat memakai contoh singkat berikut; perintah ini benar-benar memanggil model, bukan pemeriksaan offline:

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

Uji dengan versi dan setelan yang benar-benar bermasalah, lalu catat kesalahan dan penyelesaiannya. Jangan menyatakan desktop pulih hanya karena CLI lain dapat menjawab.

Jika klien secara eksplisit mengatakan model memerlukan versi yang lebih baru, selesaikan kompatibilitas versi terlebih dahulu. Pengujian pertama di sini mengalami hal itu: CLI mandiri 0.151.0 mengembalikan HTTP 400; pengujian lalu diulang memakai 0.164.0-alpha.11.1 yang disertakan dalam aplikasi. Hasil pertama tidak dihitung sebagai kegagalan jaringan.

Untuk hasil saat ini, pilihan praktisnya: terus gunakan Tailscale yang telah menyelesaikan panggilan nyata; saat mendiagnosis proxy ini, pulihkan HTTPS biasa terlebih dahulu lalu verifikasi koneksi Codex yang spesifik. Untuk menjelaskan gangguan sebelumnya, “web normal, hanya Codex lambat”, koneksi dan jalur keluar perlu dicatat bersamaan saat kondisi yang sama berhasil direproduksi.

Cakupan pengujian: data artikel berasal dari pengujian lokal langsung di Mac pada dini hari 27 Oktober 2026. Eksperimen proxy membaca parameter node AnyTLS tersimpan dan membangunnya ulang dalam proses mihomo terisolasi, tanpa menjalankan Clash GUI/TUN asli, mengganti proxy sistem, atau mengubah jalur keluar Tailscale. Walaupun pengikatan antarmuka jaringan fisik dikonfigurasi, nettop tidak menangkap antarmuka upstream yang dapat dipastikan untuk proses AnyTLS tersebut; jadi tidak dapat diklaim bahwa dua jalur fisik lengkap telah diverifikasi secara independen sepenuhnya. Hasil CLI, kanal durable desktop, dan Echo publik dicatat terpisah; data asli, skrip, dan kondisi rinci tersimpan dalam bahan eksperimen pendamping.