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. Перерваний запит, цикл перепідключення
Окрема дискусія описує збої під час віддаленого ущільнення контексту. Один коментатор пропонує перевірити проксі, але ця дискусія не встановлює підтверджену причину. Дискусія про ущільнення
Дописи на X показують схожі запитання: пост від 9 вересня описує стійкі збої потоку, тоді як пост від 6 вересня повідомляє про тайм-аут простою SSE під час віддаленого ущільнення. Жоден із них не дає порівняння DNS. Це корисні приклади проблем користувачів, але вони не встановлюють спільну причину. Звіт про потік на X, звіт про ущільнення на X
| Симптом | Що перевірити |
|---|---|
| Негайний тайм-аут із помилкою резолвера | DNS, доступність вузла та чи потрапляє трафік у Clash |
| ChatGPT працює в браузері, але Codex не працює | Відмінності в проксі, DNS, сертифікатах і вихідному трафіку |
| Вивід починається, а потім потік обривається | Довготривалі з’єднання, зміни мережі та помилки сервісу |
| Збиваються лише довгі розмови або ущільнення | Порівняйте з невеликим новим завданням; перевірте помилки сесії та сервера |
| 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 перевірте системний резолвер і його поточну відповідь:
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'
Запит використовує Cloudflare DNS JSON interface. Перевірте панель з’єднання: явний локальний проксі гарантує вхід у Clash, але правила Clash усе одно визначають кінцевий вихідний шлях.
Різні IP-адреси самі по собі не є доказом втручання. Вибір CDN, кешування, сімейства адрес і Fake-IP можуть пояснювати відмінності. Синтетична адреса з діапазону Fake-IP у Clash не є сама по собі підозрілою. Зіставте аномальну відповідь із неправильним маршрутом і збоєм, а потім порівняйте з іншим підтвердженим мережевим шляхом. За ввімкненого TUN навіть dig @resolver може бути перехоплено; це не є автоматично незалежним upstream-тестом.
Застосуйте цільове покращення Clash Verge Rev
Цей шаблон вимагає Clash Verge Rev із Mihomo, наявної підписки та робочого проксі-вузла. Це Script підписки, а не повний самостійний профіль. Спочатку створіть резервну копію поточної конфігурації. Якщо ви вже використовуєте script, інтегруйте зміну в його наявну функцію main(config). Перевірте кінцеву runtime-конфігурацію після всіх кроків покращення. Документація Clash Verge Rev Script
Параметр 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 configuration reference
Цільовий скрипт зберігає наявні налаштування 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 reference
Окремо перевірте конфігурацію, маршрутизацію та 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; якщо збій стався в десктопному застосунку, перевірте окремо його. Повторно перевіряйте після оновлення підписки, зміни мережі та переходу в режим сну/пробудження. Пізніші шари конфігурації або перейменовані групи все ще можуть зламати покращення.
Часті запитання
Чи достатньо змінити системний DNS на 8.8.8.8?
Не обов’язково. Адреса резолвера сама по собі не встановлює шифрування, маршрутизацію через проксі чи досяжність. Перевіряйте резолвер, транспорт і вихідне з’єднання разом.
Чому Codex не працює, коли Clash запущено?
Процес може обходити проксі, збігатися з прямим правилом або залежати від недоступного DNS вузла. Проблема також може бути не пов’язана з DNS. Знайдіть фактичне з’єднання, перш ніж змінювати кілька налаштувань одночасно.
Що робити, якщо він і далі від’єднується?
Якщо DNS, TLS і маршрутизація працюють, перевірте статус сервісу, розмір розмови, версію клієнта, стабільність з’єднання вузла та точний текст помилки. OpenAI документує місця для зворотного зв’язку та журналів; перед поширенням перевірте журнали на наявність секретів. Troubleshooting and logs
Як скасувати зміну?
Вимкніть доданий Script і відновіть резервну копію профілю, налаштувань TUN та будь-які змінені вами системні налаштування DNS. Окрема архітектура proxy-providers згодом може ізолювати підписки вузлів від локальних DNS і правил, але для цього цільового виправлення це не обов’язково.
Для кроків встановлення та імпорту див. Clash Verge setup. Для інших збоїв див. Clash troubleshooting. Ви можете використовувати цей діагностичний процес із наявною сумісною підпискою; купувати ще один сервіс не потрібно для перевірки DNS.