Codex медленный, а ChatGPT в браузере работает? Проверка прокси, переподключений и ошибок TLS

Когда веб-страница ChatGPT отвечает нормально, Google открывается быстро, а Codex долго не отвечает или снова и снова показывает Reconnecting, сначала изучите ошибки соединения Codex. Затем решайте, нужно ли менять узел, настраивать прокси или ждать модель.

Нормальная работа сайта доказывает лишь, что текущий маршрут браузера доступен. Она не доказывает, что запрос Codex идет через тот же прокси или что его постоянное соединение исправно. Если в журнале уже есть tls handshake eof, сброс соединения или повторные переподключения, задержку нельзя целиком приписать рассуждению модели.

Эта статья посвящена медленной работе Codex, сопровождающейся ошибками соединения. Порядок проверки: выяснить, происходит ли переподключение → проверить фактический маршрут прокси → проверить TLS и обычный HTTPS → затем проверить WebSocket или потоковое соединение.

Выводы ниже основаны на одном эксперименте на Mac: три настоящих вызова Codex завершились через Tailscale; сохраненный узел AnyTLS при изолированном повторном запуске вызвал TLS EOF, и даже HTTPS к Google не работал. Эксперимент не воспроизвел полностью исходный сценарий «веб-страница быстрая, тормозит только Codex», поэтому он не доказывает единственную причину прежнего сбоя. Он помогает определить, какой уровень проверять первым при разных свидетельствах.

Codex думает или постоянно переподключается?

Найдите ошибку, относящуюся к текущему запросу; не судите только по времени ожидания в интерфейсе.

Наблюдение или ошибка	Что проверить сначала
Reconnecting... вместе с tls handshake eof	Маршрут прокси, установление TLS и пересылку трафика к цели
stream disconnected before completion	Конкретную ошибку ниже; сама эта фраза не определяет причину
WebSocket установлен, затем прерван, код закрытия 1006	Время и длительность закрытия соответствующего соединения, промежуточные звенья
HTTP 400 с явным сообщением, что модель требует обновления	Версию клиента; не списывайте это сразу на сеть
Ошибок соединения нет, но результат долго не приходит	Пока не делайте выводов: одна лишь задержка не доказывает обрыв сети

В этом цикле использовались одна модель и один уровень рассуждения; Codex просили вернуть фиксированный текст NETWORK_PROBE_OK:

Маршрут	Результат реального вызова
Tailscale, три независимых коротких сеанса	Все завершены; весь процесс CLI занял 11.551, 13.945 и 14.877 секунды
Локальный HTTP CONNECT с выходом через Tailscale	Завершен; процесс занял 11.634 секунды
Локальный HTTP CONNECT через сохраненный узел AnyTLS	Повторные подключения; запрос не завершился за 45-секундное окно наблюдения

В неудачном вызове появились такие записи:

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

В такой ситуации дальнейшее ожидание не означает, что модель продолжает генерировать ответ. Запрос сталкивается со сбоем соединения и повторами; сначала проверьте соединение.

Указанное время включает запуск процесса, аутентификацию, рассуждение и передачу данных, это не задержка до первого токена и не чистое время сети. 45 секунд — предел остановки тестовой программы, а не среднее время ответа прокси.

Почему Codex может не подключаться, хотя веб-страница ChatGPT работает?

Отдельно проверяйте фактическое соединение браузера, настольного приложения и CLI. Расширение браузера для прокси, системный прокси, TUN, разделение трафика по процессам и переменные прокси в терминале могут охватывать разные потоки. Нельзя заключать, что одно приложение использует тот же маршрут, только потому что другое работает.

В Clash Verge проверьте три вещи:

1. Появляется ли соответствующий трафик в журнале соединений Clash в момент запроса Codex. Переменные в терминале сами по себе не подтверждают, что запрос прошел через прокси.
2. Соответствуют ли сработавшее правило и выходной маршрут ожиданиям. Проверяйте текущий запрос, а не только экран выбора узла.
3. Сравниваете ли вы один и тот же способ использования. Успех CLI не означает, что проверены все фоновые соединения настольного приложения; работающая веб-страница также не заменяет проверку соединения приложения.

В реальном тесте CLI через прокси журнал изолированного прокси показал chatgpt.com, что подтвердило прохождение запроса через эту точку входа. Контрольный HTTP CONNECT также завершил настоящий запрос, то есть в этом эксперименте клиент мог работать через эту точку входа.

Однако канал durable/app-server, на который указывал журнал настольного приложения, нужно разбирать отдельно. Документация OpenAI также отдельно описывает категории наблюдения для SSE, запросов WebSocket и событий; успех или сбой разных каналов нельзя свести к выводу «сеть Codex исправна».Категории событий телеметрии соединения Codex

Если браузер работает, а соответствующий трафик Codex не появляется в ожидаемом прокси, сначала исправьте маршрут именно этого запроса. Многократная смена узлов может вообще не повлиять на проблемное соединение.

Что проверять в первую очередь при ошибке Codex tls handshake eof?

tls handshake eof указывает, что TLS-рукопожатие завершилось преждевременно. Это не синоним ситуации «WebSocket нормально установился, а потом истекло время простоя». Сначала выясните, проходит ли обычный HTTPS через тот же прокси, и только затем изучайте постоянное соединение на уровне приложения.

Проверьте обычный HTTPS через тот же прокси

Проверьте простой HTTPS-адрес сначала через текущую системную сеть, затем через явно указанный локальный прокси. Порт локального прокси нужно брать из работающего клиента; проверка того же адреса только в браузере по-прежнему не подтверждает маршрут Codex.

Ниже примеры команд с заменяемым портом. 7897 — только пример: замените его на текущий HTTP- или mixed-порт Clash. В этом эксперименте использовался временный порт, назначенный скриптом.

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

Если сначала сообщается, что не удается подключиться к локальному порту, проверьте, запущен ли Clash и правильно ли указан порт; удаленный узел еще не проверялся. Если сбой происходит только на этапе TLS, проверьте узел и пересылку к цели. Успех обеих команд означает лишь, что доступен короткий HTTPS-запрос; затем все равно проверьте Codex.

В этом эксперименте каждую цель по каждому маршруту проверяли трижды:

Цель проверки	Маршрут Tailscale	Изолированный маршрут через сохраненный узел
Google generate_204	Во всех трех случаях HTTP 204	Во всех трех случаях curl 35, ответа HTTP нет
Главная страница ChatGPT	Во всех трех случаях HTTP 403	Во всех трех случаях curl 35, ответа HTTP нет
Неаутентифицированный GET к адресу Codex responses	Во всех трех случаях HTTP 405	Во всех трех случаях curl 35, ответа HTTP нет

curl 35 — ошибка SSL/TLS-соединения; в этом эксперименте сообщалось SSL_ERROR_SYSCALL.Описание кодов ошибок curl

Полученные 403 и 405 не означают, что функции ChatGPT или Codex работают; они показывают только, что пробный запрос получил ответ HTTP. Неаутентифицированный GET тем более не заменяет допустимый вызов модели. Настоящая проверка приложения — запрос с фиксированным маркером из предыдущего раздела.

Однако сбой HTTPS через прокси даже к Google меняет порядок проверки: сначала восстановите общую пересылку HTTPS, а не объявляйте причиной WebSocket Codex.

Доступность узла не означает, что через него можно подключиться к OpenAI

Если точка входа прокси доступна, проверьте аутентификацию, совместимость протокола и пересылку к цели.

В этом эксперименте, обойдя клиент прокси, мы привязали обычный сокет к физическому сетевому интерфейсу и подключились к четырем IPv4-адресам, полученным при разрешении имени узла. TCP-соединение успешно установилось со всеми четырьмя адресами за примерно 4–7 мс; TLS-рукопожатие с проверкой сертификата тоже прошло для всех, общее время составило примерно 248–553 мс.

Это подтверждает лишь доступность точки входа. У прокси есть последующие этапы:

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

Успешный TLS до точки входа и успешный TLS к целевому сайту через прокси — разные проверки. Первое не подтверждает прохождение аутентификации AnyTLS и не доказывает, что узел может обращаться к Google или OpenAI.

В этом эксперименте HTTPS к Google по-прежнему не работал после закрепления домена узла за одним из разрешенных IP. Контрольная локальная точка HTTP CONNECT с режимом DIRECT и выходом через Tailscale вернула Google 204. Эти сравнения смещают внимание к совместимости протокола узла с клиентом, аутентификации и состоянию пересылки, а также журналам исходящего трафика сервера, но пока не позволяют выбрать единственную причину.

Если вы получили такой же результат, следующим шагом соберите ошибки на этих этапах, а не завершайте проверку фразами «ping низкий» или «порт сервера доступен».

Нужно ли отключать WebSocket, если Codex постоянно показывает Reconnecting?

Сначала разделите две вещи: WebSocket, который использует приложение Codex, и транспортный протокол прокси-узла.

Сохраненный выбранный узел в этом эксперименте использовал AnyTLS, а не VLESS/WS из конфигурации. Поэтому предположение «этот узел работает через WS, из-за чего Codex медленный» не соответствует типу сохраненного узла. Однако собственный WebSocket Codex все еще может не работать через него.

Нужно ли проверять WebSocket, зависит от этапа соединения, подтвержденного журналом:

Имеющееся свидетельство	На чем сосредоточиться
Даже обычный HTTPS не проходит TLS-рукопожатие	Сначала исправьте установление прокси-соединения и пересылку
Обычный HTTPS работает, но рукопожатие WS не проходит	Проверьте рукопожатие данного соединения, маршрут прокси и правила доступа
WS установлен, но обрывается при работе или после простоя	Зафиксируйте момент обрыва; проверьте поддержание соединения и промежуточную сеть

В этом эксперименте постоянное соединение проверили через публичный WSS Echo Postman: через Tailscale обменяли пять сообщений, отключили активный периодический ping тестового клиента, выждали 90 секунд бездействия, затем обменяли еще пять. Все десять эхо-ответов совпали. Отключение активного ping не означает отключения TCP keepalive или кадров, которые может отправлять сервер.Описание Postman Echo

Еще одна контрольная проверка HTTP CONNECT/DIRECT также завершила WSS-рукопожатие и обмен эхо-сообщениями. Она показывает, что эта локальная точка прокси поддерживает WSS; это не доказывает исправность всех прокси-узлов. Публичный Echo также не заменяет проверку конкретной конечной точки Codex.

В историческом журнале настольного приложения нашли 10 событий websocket_error и 15 событий reconnect_started, относящихся к каналу durable. Это записи событий, а не 25 независимых сбоев: одна ошибка может распространяться на множество записей состояния.

Код 1006 означает лишь аномальное закрытие; по нему одному нельзя определить, кто оборвал соединение.Определение кода аномального закрытия WebSocket в RFC

Поэтому после появления Reconnecting не следует сразу применять настройку «отключить WS». В этом эксперименте сбой возник еще на этапе TLS, и оснований считать изменение тайм-аута простоя WebSocket подходящим исправлением пока нет.

Поможет ли Tailscale при задержках Codex?

В коротких запросах этого эксперимента на данном Mac Tailscale оказался проверенным рабочим маршрутом; это не гарантия, что он всегда быстрее. Три настоящих вызова Codex и эхо-проверка после 90 секунд простоя лучше обычного теста скорости помогают выбрать, продолжать ли его использовать сейчас.

Tailscale использует WireGuard: при возможности устанавливает прямое соединение через UDP, а если напрямую соединиться нельзя, может использовать ретранслятор. WebSocket Codex может работать внутри его туннеля; переход на Tailscale не означает отключение WebSocket.Описание типов соединений Tailscale

В 20 проверках обнаружения маршрута через Tailscale успех был в 17 случаях, тайм-аут — в трех; медиана RTT успешных проб составила 188 мс. Это нельзя считать долгосрочной долей потерь бизнес-трафика, но это также показывает, что «работает» не значит «без задержки и сбоев».

Также dig не доказывает перегрузку магистральной сети China Telecom 163. Три DNS-запроса A для домена ChatGPT завершились успешно за 185–233 мс; они измеряют DNS, а не заменяют TCP, TLS или настоящий запрос приложения. В этом эксперименте не было получено достаточных свидетельств перегрузки магистрали 163.

Если после смены выхода Codex заработал, можно подтвердить, что «изменение маршрута изменило результат». Чтобы приписать причину конкретному оператору, нагрузке общего узла или протоколу прокси, нужны отдельные подтверждающие данные.

Как убедиться, что Codex восстановился, а не просто открылась веб-страница?

Проверяйте именно тот клиент, в котором возникла проблема, а не только обновляйте главную страницу в браузере.

1. Отправьте короткий запрос без вызова инструментов. Оставьте ту же модель и уровень рассуждения; убедитесь, что получен полный результат, чтобы не смешивать выполнение инструментов с проверкой соединения.
2. Проверьте правило прокси, выходной маршрут и записи ошибок соответствующего запроса. Убедитесь, что переподключений больше нет; настроенный прокси не доказывает, что запрос прошел через него.
3. Затем проверьте исходный сценарий, который раньше не работал. Успех короткого запроса не заменяет проверку длинной задачи, восстановления после простоя или фонового канала приложения. В этом эксперименте завершился только короткий запрос к модели; восстановление длинного сценария не проверялось.

В настольном приложении можно отправить: «Не читай файлы и не вызывай инструменты; ответь только NETWORK_PROBE_OK». Пользователи CLI могут выполнить короткий пример ниже; он действительно вызывает модель, это не автономная проверка:

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

Проверяйте на фактически проблемной версии и с ее настройками, записывая ошибки и факт завершения. Не объявляйте настольное приложение исправным лишь потому, что другая CLI отвечает.

Если клиент явно сообщает, что модель требует обновления, сначала решите проблему совместимости версии. В этом эксперименте такая ошибка возникла при первой проверке: отдельный CLI 0.151.0 вернул HTTP 400; затем повторили проверку во встроенном в приложение варианте 0.164.0-alpha.11.1. Первый результат не считался сетевым сбоем.

Для текущего результата практический выбор таков: продолжать пользоваться Tailscale, через который реальный вызов уже прошел; при проверке этого прокси сначала восстановить обычный HTTPS, а затем проверить конкретное соединение Codex. Чтобы объяснить прежний сбой «веб-страница работает, только Codex медленный», нужно одновременно записывать соединения и маршрут выхода при повторном воспроизведении тех же условий.

Объем тестирования: данные статьи получены в локальных тестах на Mac ранним утром 27 октября 2026 года. Для эксперимента с прокси использовали сохраненные параметры узла AnyTLS и повторно собрали его в изолированном процессе mihomo, не запуская Clash GUI/TUN, не меняя системный прокси и маршрут выхода Tailscale. Несмотря на привязку к физическому интерфейсу, nettop не зафиксировал подтвержденный вышестоящий интерфейс этого процесса AnyTLS; поэтому нельзя утверждать, что два полных физических маршрута были полностью независимо проверены. Результаты CLI, канала durable в настольном приложении и публичного Echo записывались отдельно; исходные данные, скрипты и подробные условия сохранены в сопутствующих материалах эксперимента.