Codex ciągle się ponownie łączy? Sprawdź DNS i routing Clash

Błędy Codex, takie jak Reconnecting..., stream disconnected before completion i error sending request, mogą wiązać się z zakłóceniami DNS albo nieprawidłowym routingiem Clash. Ten przewodnik wyjaśnia, jak zbadać tę możliwość, zastosować ukierunkowane ulepszenie Clash Verge Rev i zweryfikować wynik.

Co naprawdę pokazują raporty społeczności

Użytkownicy Reddit zgłaszali przerywane zadania kierowane do chatgpt.com/backend-api/codex/responses, powtarzające się próby ponownego połączenia oraz błędy w treści odpowiedzi. Te raporty pokazują objawy, a nie diagnozę DNS. Przerwane żądanie, pętla ponownych połączeń

Oddzielna dyskusja opisuje awarie podczas zdalnego kompaktowania kontekstu. Jeden z komentujących sugeruje sprawdzenie proxy, ale dyskusja nie ustala zweryfikowanej przyczyny. Dyskusja o kompaktowaniu

Raporty na X pokazują podobne pytania: wpis z 9 września opisuje utrzymujące się awarie strumienia, a wpis z 6 września zgłasza przekroczenie czasu bezczynności SSE podczas zdalnego kompaktowania. Żaden z nich nie podaje porównania DNS. To użyteczne przykłady problemów użytkowników, ale nie ustanawiają wspólnej przyczyny. Raport o strumieniu na X, Raport o kompaktowaniu na X

Objaw	Co sprawdzić
Natychmiastowy timeout z błędem resolvera	DNS, osiągalność węzła i to, czy ruch wchodzi do Clash
ChatGPT działa w przeglądarce, ale Codex zawodzi	Różnice w proxy, DNS, certyfikatach i ruchu wychodzącym
Wyjście się zaczyna, a potem strumień się rozłącza	Długotrwałe połączenia, zmiany sieci i błędy usługi
Zawodzą tylko długie rozmowy albo kompaktowanie	Porównaj z małym nowym zadaniem; sprawdź błędy sesji i serwera
HTTP 401, 403, 429 lub 5xx	Sprawdź źródło i treść odpowiedzi pod kątem uwierzytelniania, zasad, limitów lub awarii usługi

Sprawdź status usług OpenAI i zapisz czas oraz wersję klienta. W przypadku zablokowanych czatów OpenAI zaleca również sprawdzenie oczekujących zatwierdzeń i wypróbowanie mniejszego, skoncentrowanego nowego czatu. Wersje desktop i CLI mogą się różnić. Oficjalne rozwiązywanie problemów

Lokalne badanie: nieoczekiwana odpowiedź DNS uruchomiła DIRECT

W jednym zarejestrowanym badaniu na macOS z użyciem Clash Verge Rev i Mihomo węzły proxy były osiągalne, ale chatgpt.com pasował do reguły GeoIP/CN i próbował połączenia bezpośredniego, które przekroczyło limit czasu. Porównanie z szyfrowanym DNS osiąganym przez proxy pokazało anomalię na lokalnej ścieżce rozwiązywania.

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

Istnieją dwa problemy konfiguracyjne, którymi trzeba się zająć: ścieżka rozwiązywania i decyzja routingu. Ten zarejestrowany przypadek nie jest benchmarkiem ani dowodem, że inne awarie Codex mają tę samą przyczynę. Sama anomalia odpowiedzi nie pozwala też wskazać odpowiedzialnego pośrednika ani w szczególności potwierdzić zatrucia pamięci podręcznej DNS.

Zdiagnozuj przed zmianą konfiguracji

Sprawdź dziennik połączeń

Wyszukaj w błędzie rzeczywistą nazwę hosta, w tym chatgpt.com lub openai.com. Zapisz dopasowaną regułę, łańcuch połączenia i błąd w momencie awarii. Połączenie, które powinno użyć proxy, ale wybiera DIRECT, wymaga przeglądu kolejności reguł. Mihomo ocenia reguły routingu od góry do dołu. Dokumentacja routingu

Jeśli nie pojawia się żadne dopasowane połączenie, najpierw ustal, czy ten klient używa Clash. Sukces w przeglądarce nie potwierdza ścieżki używanej przez osobny proces.

Porównaj ścieżki rozwiązywania

Na macOS sprawdź systemowy resolver i jego bieżącą odpowiedź:

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

W przypadku porównania szyfrowanego zastąp 7890 swoim portem 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'

Żądanie korzysta z interfejsu DNS JSON Cloudflare. Sprawdź panel połączeń: jawny lokalny proxy gwarantuje wejście do Clash, ale reguły Clash nadal decydują o końcowym wyjściu.

Same różne adresy IP nie są dowodem zakłóceń. Różnice mogą wynikać z wyboru CDN, buforowania, rodzin adresów i Fake-IP. Syntetyczny adres z zakresu Fake-IP Clash nie jest z natury podejrzany. Powiąż anomalię odpowiedzi z nieprawidłową trasą i awarią, a następnie porównaj z inną zweryfikowaną ścieżką sieciową. Gdy włączony jest TUN, nawet dig @resolver może zostać przechwycone; nie jest to automatycznie niezależny test upstream.

Zastosuj ukierunkowane ulepszenie Clash Verge Rev

Ten szablon wymaga Clash Verge Rev z Mihomo, istniejącej subskrypcji i działającego węzła proxy. To skrypt subskrypcji, a nie kompletna samodzielna konfiguracja. Najpierw wykonaj kopię zapasową bieżącej konfiguracji. Jeśli już używasz skryptu, zintegrować zmianę z jego istniejącą funkcją main(config). Sprawdź końcową konfigurację w czasie działania po wszystkich krokach ulepszenia. Dokumentacja skryptu Clash Verge Rev

Ustaw CODEX_PROXY_GROUP na istniejącą grupę i wybierz działający węzeł proxy w tej grupie. Ustaw NODE_DNS na resolver DoH, który działa, zanim proxy połączy się, i poprawnie rozwiązuje nazwy hostów węzłów. Przykład AliDNS służy do walidacji w sieci kontynentalnych Chin; zastąp go, gdy jest nieodpowiedni. Nie jest używany do rozwiązywania domen AI poniżej.

// 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;
}

Skrypt dodaje politykę DNS dla konkretnych domen i wstawia reguły proxy na początek, zachowując pozostałe reguły i polityki domen. Zmienia rozwiązywanie nazw hostów węzłów. Cztery sufiksy domen są punktem wyjścia, a nie wyczerpującą listą każdej funkcji Codex, niestandardowego dostawcy, usługi MCP ani pobierania zadań.

Mihomo obsługuje specyficzną dla domen politykę nameserver-policy oraz jawny sufiks proxy w adresie serwera DNS. Rozwiązywanie nazw węzłów wymaga niezależnej ścieżki, aby uniknąć zależności cyklicznej. DNS configuration reference

Ukierunkowany skrypt zachowuje istniejące ustawienia fallback. Przed ich zastąpieniem osobno przejrzyj szersze zależności DNS. Sprawdź też, czy nie ma przestarzałych mapowań hosts lub konfliktujących, bardziej szczegółowych polityk.

Sprawdź TUN osobno

Dla procesów, które nie używają systemowego proxy, włącz TUN w Clash Verge Rev i sprawdź, czy działa. Scal poniższe pola z istniejącym obiektem TUN, zachowując jego pozostałe ustawienia:

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

Dotyczy to DNS UDP i TCP na porcie 53. Mihomo dokumentuje ograniczenia dla DNS kierowanego do LAN na macOS i Windows; szyfrowany DNS zarządzany przez aplikację również nie podlega tym regułom portu 53. Zamiast zakładać, że przełącznik obejmuje każde żądanie, zweryfikuj zachowanie resolvera i interfejsu. TUN reference

Zweryfikuj osobno konfigurację, routing i Codex

Najpierw sprawdź finalną konfigurację pod kątem błędów, odwołań do grup i kolejności reguł. Jeśli dostępne jest CLI Mihomo, mihomo -t -f <final-config-path> sprawdza, czy konfiguracja się parsuje. Nie potwierdza to łączności.

Następnie sprawdź rzeczywisty routing połączenia i uruchom probe HTTPS z weryfikacją certyfikatu przez swój rzeczywisty lokalny port:

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/

Odpowiedź od zamierzonej usługi po pomyślnej weryfikacji certyfikatu ustanawia wymianę HTTP dla tego probe. Kod 401 lub 403 nadal może blokować dostęp. Nie dowodzi to, że uwierzytelnione żądanie Codex działa, a wyłączenie weryfikacji certyfikatu unieważniłoby ten test.

Na koniec ukończ w kliencie małe zadanie, które wcześniej się nie powiodło. Zainstalowane, uwierzytelnione CLI może uruchomić poniższy opcjonalny test, który wykonuje rzeczywiste żądanie do modelu i korzysta z limitu konta:

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

Sukces CLI potwierdza tylko to jedno żądanie CLI; przetestuj aplikację desktopową osobno, jeśli to tam wystąpiła awaria. Sprawdź ponownie po aktualizacji subskrypcji, zmianie sieci oraz uśpieniu/wybudzeniu. Późniejsze warstwy konfiguracji lub przemianowane grupy nadal mogą zepsuć usprawnienie.

Najczęściej zadawane pytania

Czy wystarczy zmienić systemowy DNS na 8.8.8.8?

Niekoniecznie. Sam adres resolvera nie ustanawia szyfrowania, routingu proxy ani osiągalności. Zweryfikuj razem resolver, transport i wyjście.

Dlaczego Codex zawodzi, gdy działa Clash?

Proces może omijać proxy, pasować do reguły direct albo zależeć od niedostępnego DNS węzła. Problem może też nie mieć związku z DNS. Znajdź rzeczywiste połączenie, zanim zmienisz kilka ustawień naraz.

Co jeśli nadal się rozłącza?

Jeśli DNS, TLS i routing działają, sprawdź stan usługi, rozmiar rozmowy, wersję klienta, stabilność połączenia węzła i dokładną treść błędu. OpenAI dokumentuje lokalizacje opinii i logów; przed udostępnieniem przejrzyj logi pod kątem sekretów. Troubleshooting and logs

Jak cofnąć zmianę?

Wyłącz dodany Script i przywróć kopię zapasową profilu, ustawienia TUN oraz wszelkie ustawienia systemowego DNS, które zmieniłeś. Osobna architektura proxy-providers może później odizolować subskrypcje węzłów od lokalnego DNS i reguł, ale nie jest wymagana dla tej ukierunkowanej poprawki.

W sprawie kroków instalacji i importu zobacz Clash Verge setup. W przypadku innych awarii zobacz Clash troubleshooting. Możesz użyć tego procesu diagnostycznego z istniejącą zgodną subskrypcją; zakup kolejnej usługi nie jest warunkiem wstępnym testowania DNS.