Codex chậm nhưng ChatGPT trên web bình thường? Cách kiểm tra proxy, kết nối lại và lỗi TLS

Nếu ChatGPT trên web trò chuyện bình thường, Google tải nhanh nhưng Codex vẫn chậm phản hồi hoặc liên tục hiện Reconnecting, hãy xem lỗi kết nối của Codex trước khi quyết định đổi máy chủ, chỉnh proxy hay chờ mô hình.

Trang web hoạt động bình thường chỉ chứng minh đường truy cập hiện tại của trình duyệt dùng được; điều đó không chứng minh yêu cầu Codex đi qua cùng proxy hoặc kết nối duy trì của nó ổn định. Nếu nhật ký đã có tls handshake eof, kết nối bị đặt lại hay liên tục kết nối lại, không thể quy toàn bộ thời gian chờ cho quá trình suy luận của mô hình.

Bài viết này dành cho tình trạng Codex chậm kèm lỗi kết nối. Thứ tự kiểm tra là: xác định có đang kết nối lại không → xác nhận đường proxy thực tế → kiểm tra TLS và HTTPS thông thường → rồi kiểm tra WebSocket hoặc kết nối truyền luồng.

Các nhận định dưới đây dựa trên một lần thử trực tiếp trên máy Mac: ba yêu cầu Codex thật hoàn tất qua Tailscale; nút AnyTLS đã lưu gặp TLS EOF khi dựng lại trong môi trường cô lập, và ngay cả HTTPS tới Google cũng thất bại. Lần thử này không tái hiện đầy đủ tình huống ban đầu “web nhanh, chỉ Codex chậm”, nên không thể coi đây là nguyên nhân duy nhất của sự cố trước đó. Kết quả giúp xác định nên kiểm tra lớp nào trước khi có từng loại bằng chứng.

Codex đang suy nghĩ hay liên tục kết nối lại?

Tìm lỗi gắn với yêu cầu hiện tại; đừng chỉ nhìn thời gian giao diện chờ.

Hiện tượng hoặc lỗi	Việc cần kiểm tra trước
`Reconnecting...` cùng với `tls handshake eof`	Đường proxy, bắt tay TLS và chuyển tiếp tới đích
`stream disconnected before completion`	Lỗi cụ thể phía sau; riêng câu này chưa xác định được nguyên nhân
WebSocket đã kết nối rồi bị ngắt, mã đóng 1006	Thời điểm, thời lượng đóng kết nối đó và các chặng trung gian
HTTP 400 nêu rõ mô hình cần phiên bản mới hơn	Phiên bản máy khách; đừng vội quy cho mạng
Không có lỗi kết nối nhưng chờ kết quả lâu	Tạm giữ kết luận; chỉ chậm thôi chưa chứng minh mạng bị ngắt

Lần kiểm tra này dùng cùng mô hình và cùng mức suy luận, chỉ yêu cầu Codex trả về văn bản cố định NETWORK_PROBE_OK:

Đường kết nối	Kết quả yêu cầu thực tế
Tailscale, ba phiên ngắn độc lập	Cả ba hoàn tất; toàn bộ tiến trình CLI lần lượt mất 11.551, 13.945 và 14.877 giây
HTTP CONNECT cục bộ, đi ra qua Tailscale	Hoàn tất; toàn bộ tiến trình mất 11.634 giây
HTTP CONNECT cục bộ, dùng nút AnyTLS đã lưu	Liên tục kết nối lại; không hoàn tất trong cửa sổ quan sát 45 giây

Yêu cầu thất bại ghi lại các dòng sau:

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

Trong trường hợp này, chờ thêm không có nghĩa mô hình vẫn đang tạo câu trả lời. Yêu cầu đang gặp lỗi kết nối và thử lại; hãy kiểm tra kết nối trước.

Các mốc thời gian trong bảng bao gồm khởi động tiến trình, xác thực, suy luận và truyền dữ liệu, không phải độ trễ token đầu tiên hay thời gian mạng thuần túy. 45 giây là giới hạn dừng của chương trình kiểm tra, không phải thời gian phản hồi trung bình của proxy.

Vì sao Codex vẫn có thể không kết nối dù ChatGPT trên web hoạt động?

Hãy xác nhận riêng kết nối thực tế của trình duyệt, ứng dụng máy tính và CLI. Tiện ích proxy của trình duyệt, proxy hệ thống, TUN, phân luồng theo tiến trình và biến môi trường proxy trong terminal có thể áp dụng cho các phạm vi khác nhau. Không thể suy ra một chương trình đi cùng tuyến với chương trình khác chỉ vì chương trình kia hoạt động.

Trong Clash Verge, trước tiên kiểm tra ba điểm:

Nhật ký kết nối Clash có ghi nhận lưu lượng tương ứng khi Codex gửi yêu cầu hay không. Đặt biến trong terminal chưa xác nhận yêu cầu thật sự đi qua proxy.
Quy tắc được áp dụng và tuyến thoát có đúng như dự kiến không. Kiểm tra yêu cầu hiện tại, không chỉ nhìn màn hình chọn nút.
Bạn đang so sánh cùng cách sử dụng hay không. CLI chạy được không chứng minh mọi kết nối nền của ứng dụng máy tính đều chạy được; web trò chuyện bình thường cũng không thay cho việc kiểm tra ứng dụng máy tính.

Trong lần thử proxy CLI thực tế này, nhật ký kết nối của proxy cô lập có chatgpt.com, xác nhận yêu cầu đi vào điểm đầu proxy đó. Đối chứng HTTP CONNECT cũng hoàn tất yêu cầu thật, cho thấy trong lần thử này máy khách có thể hoạt động qua điểm đầu đó.

Tuy vậy, kênh durable/app-server báo lỗi trong nhật ký ứng dụng máy tính cần được phân tích riêng. Tài liệu OpenAI cũng phân loại riêng dữ liệu quan sát về SSE, yêu cầu WebSocket và sự kiện; không nên gộp thành một kết luận “mạng Codex bình thường”.Phân loại sự kiện telemetry kết nối Codex

Nếu trình duyệt hoạt động nhưng lưu lượng Codex tương ứng không xuất hiện ở proxy dự kiến, hãy sửa tuyến proxy của chính yêu cầu đó trước. Đổi nút nhiều lần có thể chẳng thay đổi kết nối đang lỗi.

Nên kiểm tra gì trước khi Codex báo `tls handshake eof`?

tls handshake eof cho biết quá trình bắt tay TLS kết thúc sớm. Nó không đồng nghĩa với việc “WebSocket đã kết nối bình thường rồi mới hết thời gian chờ khi nhàn rỗi”. Trước tiên xác nhận HTTPS thông thường có hoạt động qua cùng proxy không, rồi mới xem xét kết nối duy trì ở tầng ứng dụng.

Kiểm tra HTTPS thông thường qua cùng proxy

Thử một địa chỉ HTTPS đơn giản qua mạng hệ thống hiện tại và qua proxy cục bộ được chỉ định rõ. Cổng proxy cục bộ phải lấy từ ứng dụng đang chạy; chỉ mở cùng địa chỉ trong trình duyệt vẫn không xác nhận được tuyến Codex sử dụng.

Đây là ví dụ lệnh có thể thay cổng. 7897 chỉ là giá trị minh họa; hãy đổi thành cổng HTTP hoặc mixed hiện tại của Clash. Lần thử này thực tế dùng một cổng tạm do tập lệnh cấp.

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

Nếu lỗi đầu tiên báo không kết nối được cổng cục bộ, hãy xác nhận Clash đang chạy và cổng nhập đúng; khi đó bạn chưa kiểm tra được nút từ xa. Nếu chỉ thất bại ở bước TLS, hãy kiểm tra nút và chuyển tiếp tới đích. Cả hai lệnh thành công chỉ cho thấy HTTPS ngắn hoạt động; vẫn cần kiểm tra Codex.

Lần thử này kiểm tra mỗi đích trên mỗi tuyến ba lần:

Đích kiểm tra	Tuyến Tailscale	Tuyến proxy cô lập qua nút đã lưu
Google `generate_204`	Cả ba lần đều HTTP 204	Cả ba lần đều curl 35, không có phản hồi HTTP
Trang chủ ChatGPT	Cả ba lần đều HTTP 403	Cả ba lần đều curl 35, không có phản hồi HTTP
GET chưa xác thực tới địa chỉ Codex responses	Cả ba lần đều HTTP 405	Cả ba lần đều curl 35, không có phản hồi HTTP

curl 35 là lỗi kết nối SSL/TLS; thông báo lần này là SSL_ERROR_SYSCALL.Giải thích mã lỗi curl

Các mã 403 và 405 ở đây không có nghĩa chức năng ChatGPT hay Codex hoạt động bình thường; chúng chỉ cho biết phép thăm dò nhận được phản hồi HTTP. GET chưa xác thực càng không thể thay cho yêu cầu mô hình hợp lệ. Phép kiểm tra ứng dụng thật là yêu cầu trả dấu mốc cố định ở phần trước.

Dù vậy, proxy còn không tải được HTTPS của Google đã đủ để đổi thứ tự xử lý: khôi phục chuyển tiếp HTTPS thông thường trước, thay vì vội quy lỗi cho WebSocket của Codex.

Kết nối được tới nút không có nghĩa nút kết nối được tới OpenAI

Nếu điểm đầu proxy kết nối được, tiếp theo vẫn cần kiểm tra xác thực, khả năng tương thích giao thức và trạng thái chuyển tiếp tới đích.

Trong lần thử này, bỏ qua ứng dụng proxy, gắn socket gốc vào card mạng vật lý và lần lượt kết nối tới bốn địa chỉ IPv4 phân giải từ nút. Cả bốn kết nối TCP đều thành công trong khoảng 4–7 ms; bắt tay TLS có xác minh chứng chỉ cũng thành công, tổng thời gian khoảng 248–553 ms.

Điều này chỉ chứng minh điểm đầu có thể truy cập. Đường proxy còn các bước sau:

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

TLS tới điểm đầu thành công và TLS tới trang đích thông qua proxy thành công là hai phép kiểm tra khác nhau. Kết quả đầu không chứng minh xác thực AnyTLS đã qua, cũng không chứng minh nút truy cập được Google hoặc OpenAI.

Lần thử này vẫn không tải được HTTPS tới Google sau khi cố định tên miền nút thành một IP đã phân giải. Đối chứng HTTP CONNECT cục bộ chuyển sang DIRECT và đi ra qua Tailscale lại nhận được Google 204. Các đối chiếu này hướng sự chú ý tới khả năng tương thích giữa giao thức nút và máy khách, xác thực và trạng thái chuyển tiếp, cùng nhật ký lưu lượng ra ở máy chủ, nhưng chưa đủ để chọn một nguyên nhân duy nhất.

Nếu kết quả của bạn giống vậy, bước tiếp theo là lấy nhật ký lỗi ở các khâu này, thay vì kết thúc điều tra bằng “ping thấp” hoặc “kết nối được cổng máy chủ”.

Codex liên tục Reconnecting, có nên tắt WebSocket không?

Trước hết phân biệt hai thứ: WebSocket mà ứng dụng Codex sử dụng và giao thức truyền tải của nút proxy.

Nút được chọn và lưu trong lần thử này là AnyTLS, không phải nút VLESS/WS trong cấu hình. Vì vậy, giả thuyết “nút này dùng WS nên Codex chậm” không phù hợp với loại nút đã lưu. Tuy nhiên, WebSocket riêng của Codex đi qua nút đó vẫn có thể thất bại.

Có cần kiểm tra WebSocket hay không phụ thuộc kết nối đã đi tới bước nào:

Bằng chứng hiện có	Trọng tâm kiểm tra
HTTPS thông thường cũng không bắt tay TLS được	Sửa việc kết nối proxy và chuyển tiếp trước
HTTPS thông thường tốt nhưng bắt tay WS thất bại	Kiểm tra bắt tay, tuyến proxy và chính sách truy cập của kết nối đó
WS đã kết nối nhưng ngắt khi dùng hoặc sau thời gian nhàn rỗi	Ghi lại thời điểm ngắt; kiểm tra duy trì kết nối và các chặng trung gian

Lần thử này xác nhận kết nối duy trì qua dịch vụ WSS Echo công khai của Postman: qua Tailscale, gửi năm tin nhắn, tắt ping định kỳ chủ động của máy khách kiểm tra, để yên 90 giây rồi gửi thêm năm tin. Cả mười phản hồi echo đều khớp. Tắt ping chủ động không đồng nghĩa đã tắt TCP keepalive hoặc các frame máy chủ có thể gửi.Giới thiệu dịch vụ Postman Echo

Một đối chứng HTTP CONNECT/DIRECT khác cũng hoàn tất bắt tay WSS và echo. Kết quả cho thấy điểm proxy cục bộ này có thể mang WSS, không thể khái quát rằng mọi nút proxy đều hoạt động; dịch vụ Echo công khai cũng không thay cho endpoint cụ thể của Codex.

Trong nhật ký ứng dụng máy tính cũ, tìm thấy rõ 10 sự kiện websocket_error và 15 sự kiện reconnect_started liên quan tới kênh durable. Đây là các bản ghi sự kiện, không phải 25 lỗi độc lập; một lỗi có thể lan sang nhiều bản ghi trạng thái.

Mã đóng 1006 chỉ cho biết kết nối đóng bất thường; riêng mã này không xác định được bên nào đã ngắt kết nối.Định nghĩa RFC về mã đóng bất thường của WebSocket

Vì vậy, khi thấy Reconnecting, đừng áp dụng ngay cấu hình “tắt WS”. Lần thử này thất bại ngay từ giai đoạn TLS; chưa có bằng chứng cho thấy sửa thời gian chờ nhàn rỗi của WebSocket là cách khắc phục phù hợp.

Chuyển sang Tailscale có khắc phục Codex bị khựng không?

Trong các yêu cầu ngắn của lần thử trên máy Mac này, Tailscale là tuyến đã được xác minh hoạt động; đây không phải bảo đảm rằng nó luôn nhanh hơn. Ba yêu cầu Codex thực và phép echo sau 90 giây nhàn rỗi hỗ trợ lựa chọn dùng tiếp trong hiện tại tốt hơn phép đo tốc độ đơn thuần.

Tailscale dùng WireGuard, truyền qua UDP khi có thể kết nối trực tiếp và có thể dùng relay nếu không kết nối trực tiếp được. WebSocket của Codex có thể chạy trong đường hầm đó; chuyển sang Tailscale không có nghĩa đã tắt WebSocket.Giải thích các loại kết nối Tailscale

Trong 20 lần dò khám phá của Tailscale, có 17 lần thành công, 3 lần hết thời gian; RTT trung vị của các mẫu thành công là 188 ms. Con số này không thể coi là tỷ lệ mất gói lâu dài của lưu lượng thực tế, nhưng cũng cho thấy “dùng được” không đồng nghĩa “không trễ, không lỗi”.

Tương tự, dig không chứng minh mạng trục 163 bị nghẽn. Ba lần truy vấn A cho tên miền ChatGPT đều thành công trong 185–233 ms; chúng đo DNS, không thay thế kiểm tra TCP, TLS hay yêu cầu ứng dụng thật. Lần thử này không có đủ bằng chứng tuyến đường để xác nhận mạng trục 163 bị nghẽn.

Nếu Codex hồi phục sau khi đổi tuyến thoát, có thể xác nhận rằng “đổi tuyến đã làm thay đổi kết quả”. Muốn quy nguyên nhân cho một nhà mạng, tải trên nút dùng chung hay giao thức proxy cụ thể, cần bằng chứng tương ứng với nhận định đó.

Làm sao xác nhận Codex đã hồi phục, thay vì chỉ tình cờ mở được trang web?

Kiểm tra trong chính máy khách gặp vấn đề, không chỉ quay lại tải mới trang chủ trong trình duyệt.

Gửi yêu cầu ngắn không gọi công cụ. Giữ nguyên mô hình và mức suy luận, xác nhận nhận được câu trả lời đầy đủ để không trộn thời gian chạy công cụ vào phép thử kết nối.
Xác nhận quy tắc proxy, tuyến thoát và nhật ký lỗi của yêu cầu tương ứng. Kiểm tra còn kết nối lại không; đã đặt proxy không đồng nghĩa yêu cầu thật sự đi qua nó.
Sau đó thử lại quy trình từng bị lỗi. Yêu cầu ngắn thành công không thay cho kiểm tra tác vụ dài, khôi phục sau thời gian nhàn rỗi hay kênh nền của ứng dụng máy tính. Lần này chỉ hoàn tất yêu cầu mô hình ngắn, chưa chứng minh quy trình dài đã hồi phục.

Trong ứng dụng máy tính, có thể gửi: “Đừng đọc tệp hoặc gọi công cụ, chỉ trả lời NETWORK_PROBE_OK”. Người dùng CLI có thể tham khảo lệnh ngắn dưới đây; lệnh gọi mô hình thật, không phải kiểm tra ngoại tuyến:

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

Hãy xác minh bằng đúng phiên bản và thiết lập đang gặp lỗi, đồng thời ghi lại lỗi và trạng thái hoàn tất. Đừng tuyên bố ứng dụng máy tính đã hồi phục chỉ vì một CLI khác trả lời được.

Nếu máy khách báo rõ mô hình cần phiên bản mới, trước tiên xử lý khả năng tương thích phiên bản. Lần thử đầu tiên ở đây gặp đúng tình huống đó: CLI độc lập 0.151.0 trả HTTP 400; sau đó thử lại bằng bản 0.164.0-alpha.11.1 đi kèm ứng dụng. Kết quả đầu không được tính là lỗi mạng.

Với kết quả hiện tại, lựa chọn thực tế là tiếp tục dùng Tailscale, tuyến đã hoàn tất yêu cầu thật; khi xử lý proxy này, khôi phục HTTPS thông thường trước rồi xác minh kết nối Codex cụ thể. Muốn giải thích sự cố trước đây “web bình thường nhưng chỉ Codex chậm”, cần ghi đồng thời kết nối và tuyến thoát khi tái hiện đúng điều kiện đó.

Phạm vi kiểm tra: dữ liệu bài viết đến từ lần thử trực tiếp trên máy Mac vào sáng sớm ngày 27 tháng 10 năm 2026. Thí nghiệm proxy đọc thông số nút AnyTLS đã lưu và dựng lại trong tiến trình mihomo cô lập, không khởi chạy Clash GUI/TUN gốc, không đổi proxy hệ thống hay tuyến thoát Tailscale. Dù đã cấu hình gắn vào card mạng vật lý, nettop không ghi nhận được giao diện thượng nguồn có thể xác nhận cho tiến trình AnyTLS; vì vậy không thể khẳng định hai tuyến vật lý hoàn chỉnh đã được xác minh độc lập hoàn toàn. Kết quả CLI, kênh durable của ứng dụng máy tính và Echo công khai được ghi riêng; dữ liệu gốc, tập lệnh và điều kiện chi tiết nằm trong tài liệu thí nghiệm đi kèm.