Codex постоянно переподключается? Проверьте DNS и маршрутизацию Clash

Ошибки Codex, такие как Reconnecting..., stream disconnected before completion и error sending request, могут быть связаны с вмешательством в DNS или некорректной маршрутизацией Clash. В этом руководстве объясняется, как исследовать эту возможность, применить точечное улучшение Clash Verge Rev и проверить результат.

Что на самом деле показывают сообщения сообщества

Пользователи Reddit сообщали о прерванных задачах, обращающихся к chatgpt.com/backend-api/codex/responses, повторяющихся попытках переподключения и ошибках тела ответа. Эти сообщения фиксируют симптомы, а не подтверждают DNS-диагноз. Прерванный запрос, цикл переподключения

В отдельном обсуждении описываются сбои во время удалённого уплотнения контекста. Один из комментаторов предлагает проверить прокси, но обсуждение не устанавливает подтверждённую причину. Обсуждение compaction

Сообщения в X показывают похожие вопросы: пост от 9 сентября описывает постоянные сбои потока, а пост от 6 сентября сообщает о тайм-ауте простоя SSE во время удалённого compaction. Ни один из них не содержит сравнения DNS. Это полезные примеры пользовательских проблем, но они не подтверждают общую причину. Отчёт о сбое потока в X, Отчёт о compaction в X

Симптом	Что следует проверить
Немедленный тайм-аут с ошибкой resolver	DNS, доступность узла и входит ли трафик в Clash
ChatGPT работает в браузере, а Codex — нет	Различия в прокси, DNS, сертификатах и egress
Вывод начинается, затем поток отключается	Долгоживущие соединения, изменения сети и ошибки сервиса
Сбой происходит только в длинных диалогах или при compaction	Сравните с небольшой новой задачей; проверьте ошибки сессии и сервера
HTTP 401, 403, 429 или 5xx	Проверьте источник и тело ответа на предмет сбоев аутентификации, политики, лимитов или сервиса

Проверьте статус сервиса OpenAI и запишите время и версию клиента. Для зависших чатов OpenAI также рекомендует проверить ожидающие подтверждения и попробовать меньший, сфокусированный новый чат. Версии Desktop и CLI могут различаться. Официальное руководство по устранению неполадок

Локальный случай: неожиданный DNS-ответ вызвал DIRECT

В одном задокументированном расследовании на macOS с использованием Clash Verge Rev и Mihomo прокси-узлы были доступны, но chatgpt.com соответствовал правилу GeoIP/CN и пытался установить прямое соединение, которое завершалось тайм-аутом. Сравнение с зашифрованным DNS, доступным через прокси, показало аномальный ответ на локальном пути разрешения.

Request to chatgpt.com
  → anomalous DNS answer
  → no earlier matching OpenAI domain rule
  → GeoIP selects DIRECT
  → connection times out and Codex retries

Здесь нужно устранить две проблемы конфигурации: путь разрешения и решение о маршрутизации. Этот задокументированный случай не является эталоном и не доказывает, что у других сбоев Codex та же причина. Один лишь аномальный ответ также не позволяет определить ответственного посредника или подтвердить именно отравление DNS-кэша.

Проводите диагностику до изменения конфигурации

Проверьте журнал соединений

Найдите фактическое имя хоста в ошибке, включая chatgpt.com или openai.com. Запишите совпавшее правило, цепочку соединения и ошибку на момент сбоя. Если соединение должно использовать прокси, но выбирает DIRECT, стоит проверить порядок правил. Mihomo оценивает правила маршрутизации сверху вниз. Документация по маршрутизации

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

Сравните пути разрешения

На macOS проверьте системный resolver и его текущий ответ:

scutil --dns
dscacheutil -q host -a name chatgpt.com

Для зашифрованного сравнения замените 7890 на ваш HTTP/mixed-порт Clash:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=chatgpt.com&type=A'

Запрос использует DNS JSON interface от Cloudflare. Проверьте панель соединений: явный локальный прокси гарантирует вход в Clash, но правила Clash всё равно определяют итоговый egress.

Одни только разные IP-адреса не являются доказательством вмешательства. Различия могут объясняться выбором CDN, кэшированием, семействами адресов и Fake-IP. Синтетический адрес из диапазона Fake-IP Clash сам по себе не подозрителен. Соотнесите аномальный ответ с неправильным маршрутом и сбоем, затем сравните его с другим проверенным сетевым путём. При включённом TUN даже dig @resolver может быть перехвачен; это не становится автоматически независимой проверкой вышестоящего узла.

Примените точечное улучшение Clash Verge Rev

Этот шаблон требует Clash Verge Rev с Mihomo, существующую подписку и работающий прокси-узел. Это Script для подписки, а не полный автономный профиль. Сначала создайте резервную копию текущей конфигурации. Если вы уже используете script, интегрируйте изменение в его существующую функцию main(config). Проверьте итоговую runtime-конфигурацию после всех шагов улучшения. Документация по Script в Clash Verge Rev

Установите CODEX_PROXY_GROUP на существующую группу и выберите в этой группе рабочий прокси-узел. Установите NODE_DNS на DoH-резолвер, который работает до подключения прокси и корректно разрешает имена хостов узлов. Пример AliDNS предназначен для проверки в сети материкового Китая; замените его, если он не подходит. Он не используется для разрешения AI-доменов ниже.

// Clash Verge Rev subscription Script. Use with an existing Mihomo profile.
// Replace this with the exact name of a working proxy group in that profile.
const CODEX_PROXY_GROUP = "REPLACE_WITH_EXISTING_PROXY_GROUP";

// Example bootstrap resolver for a mainland-China network. Verify reachability
// and node-hostname answers on your network, or replace with your trusted DoH.
// It must work BEFORE the proxy is established. It does not resolve AI domains.
const NODE_DNS = ["https://223.5.5.5/dns-query#DIRECT"];

function main(config) {
  const groups = config["proxy-groups"] || [];
  if (!groups.some((group) => group.name === CODEX_PROXY_GROUP)) {
    throw new Error("Set CODEX_PROXY_GROUP to an existing working proxy group.");
  }
  if (/[#&,\r\n]/.test(CODEX_PROXY_GROUP)) {
    throw new Error("Use a proxy group name without #, &, commas or newlines.");
  }

  const domains = ["chatgpt.com", "openai.com", "oaistatic.com", "oaiusercontent.com"];
  const doh = [
    "https://1.1.1.1/dns-query#" + CODEX_PROXY_GROUP,
    "https://8.8.8.8/dns-query#" + CODEX_PROXY_GROUP,
  ];
  const dns = config.dns || {};
  const policy = Object.assign({}, dns["nameserver-policy"] || {});
  domains.forEach((domain) => { policy["+." + domain] = doh.slice(); });
  dns.enable = true;
  dns["nameserver-policy"] = policy;
  dns["proxy-server-nameserver"] = NODE_DNS.slice();
  if (!Array.isArray(dns.nameserver) || dns.nameserver.length === 0) {
    dns.nameserver = NODE_DNS.slice();
  }
  config.dns = dns;

  const oldRules = Array.isArray(config.rules) ? config.rules : [];
  const aiRules = domains.map((domain) =>
    "DOMAIN-SUFFIX," + domain + "," + CODEX_PROXY_GROUP
  );
  config.rules = aiRules.concat(oldRules.filter((rule) => !aiRules.includes(rule)));
  return config;
}

Скрипт добавляет DNS-политику для конкретных доменов и вставляет правила прокси в начало, сохраняя остальные правила и политики доменов. Он изменяет разрешение имён хостов узлов. Четыре суффикса доменов — это стартовый охват, а не исчерпывающий список всех функций Codex, пользовательских провайдеров, сервисов MCP или загрузок задач.

Mihomo поддерживает nameserver-policy для конкретных доменов и явный суффикс прокси в адресе DNS-сервера. Для разрешения узлов требуется независимый путь, чтобы избежать циклической зависимости. Справочник по настройке DNS

Целевой скрипт сохраняет существующие настройки fallback. Перед их заменой отдельно проверьте более широкие зависимости DNS. Также проверьте наличие устаревших сопоставлений hosts или конфликтующих, более специфичных политик.

Проверьте TUN отдельно

Для процессов, которые не используют системный прокси, включите TUN в Clash Verge Rev и убедитесь, что он запущен. Объедините следующие поля с вашим существующим объектом TUN, сохранив остальные его настройки:

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

Они охватывают DNS по UDP и TCP на порту 53. В документации Mihomo указаны ограничения для DNS, направленного в LAN, на macOS и Windows; зашифрованный DNS, управляемый приложением, также не подпадает под эти правила для порта 53. Проверяйте поведение резолвера и интерфейса, а не исходите из того, что этот переключатель охватывает каждый запрос. Справочник по TUN

Отдельно проверьте конфигурацию, маршрутизацию и Codex

Сначала проверьте итоговую конфигурацию на ошибки, ссылки на группы и порядок правил. Если доступен CLI Mihomo, mihomo -t -f <final-config-path> проверяет, разбирается ли конфигурация. Это не доказывает наличие соединения.

Затем проверьте фактическую маршрутизацию соединения и выполните HTTPS-проверку с верификацией сертификата через ваш реальный локальный порт:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'HTTP=%{http_code} TLS=%{time_appconnect}s TOTAL=%{time_total}s\n' \
  https://chatgpt.com/

Ответ от предполагаемого сервиса после успешной проверки сертификата подтверждает HTTP-обмен для этой проверки. 401 или 403 всё ещё могут блокировать доступ. Это не доказывает, что аутентифицированный запрос Codex работает, а отключение проверки сертификата сделает эту проверку недействительной.

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

codex exec --skip-git-repo-check --sandbox read-only \
  'Reply with exactly: PONG. Do not use tools.'

Успех в CLI подтверждает только этот запрос CLI; отдельно протестируйте desktop-приложение, если сбой происходил именно там. Повторно проверьте после обновления подписки, смены сети и перехода в сон/пробуждения. Более поздние слои конфигурации или переименованные группы всё ещё могут нарушить это улучшение.

Часто задаваемые вопросы

Достаточно ли изменить системный DNS на 8.8.8.8?

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

Почему Codex не работает, хотя Clash запущен?

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

Что делать, если он всё ещё отключается?

Если DNS, TLS и маршрутизация работают, проверьте статус сервиса, размер разговора, версию клиента, стабильность соединения узла и точное содержимое ошибки. OpenAI документирует места для обратной связи и логов; перед публикацией проверьте логи на наличие секретов. Устранение неполадок и логи

Как отменить изменение?

Отключите добавленный Script и восстановите резервную копию профиля, настройки TUN и все системные настройки DNS, которые вы изменяли. Отдельная архитектура proxy-providers позже может изолировать подписки узлов от локального DNS и правил, но для этого целевого исправления не требуется.

Шаги по установке и импорту см. в настройке Clash Verge. О других сбоях см. устранение неполадок Clash. Вы можете использовать этот процесс диагностики с существующей совместимой подпиской; покупка другого сервиса не является обязательным условием для тестирования DNS.