Codex가 계속 재연결되나요? DNS와 Clash 라우팅을 확인하세요

Reconnecting..., stream disconnected before completion, error sending request 같은 Codex 오류에는 DNS 간섭이나 잘못된 Clash 라우팅이 관련될 수 있습니다. 이 가이드는 그런 가능성을 조사하고, 목표를 좁힌 Clash Verge Rev 향상을 적용한 다음, 결과를 확인하는 방법을 설명합니다.

커뮤니티 보고가 실제로 보여주는 것

Reddit 사용자들은 chatgpt.com/backend-api/codex/responses를 대상으로 한 작업 중단, 반복적인 재연결 시도, 그리고 응답 본문 오류를 보고했습니다. 이러한 보고는 증상을 보여줄 뿐, DNS 진단을 확정하지는 않습니다. Interrupted request, reconnection loop

별도의 토론에서는 원격 컨텍스트 압축 중 실패를 설명합니다. 한 댓글은 프록시를 조사해 보라고 제안하지만, 그 토론만으로는 검증된 원인을 확정하지 않습니다. Compaction discussion

X의 보고도 비슷한 질문을 보여 줍니다. 9월 9일 게시물은 지속적인 스트림 실패를 설명하고, 9월 6일 게시물은 원격 압축 중 SSE idle timeout을 보고합니다. 어느 쪽도 DNS 비교를 제공하지 않습니다. 이는 사용자 문제의 유용한 예시이지만, 공통 원인을 입증하지는 않습니다. X stream report, X compaction report

증상	조사할 항목
확인자 오류와 함께 즉시 타임아웃	DNS, 노드 도달 가능성, 그리고 트래픽이 Clash에 들어가는지 여부
브라우저에서는 ChatGPT가 작동하지만 Codex는 실패	프록시, DNS, 인증서, egress의 차이
출력은 시작되지만 이후 스트림이 끊어짐	장시간 연결, 네트워크 변경, 서비스 오류
긴 대화 또는 압축만 실패	작은 새 작업과 비교하고 세션 및 서버 오류를 조사
HTTP 401, 403, 429, 또는 5xx	인증, 정책, 제한, 또는 서비스 실패를 위해 응답 출처와 본문을 점검

OpenAI 서비스 상태를 확인하고 시간과 클라이언트 버전을 기록하세요. 멈춘 채팅의 경우 OpenAI는 대기 중인 승인 여부를 확인하고 더 작고 초점을 맞춘 새 채팅을 시도할 것을 권장합니다. 데스크톱과 CLI 버전은 다를 수 있습니다. 공식 문제 해결

로컬 사례: 예상치 못한 DNS 응답이 DIRECT를 유발함

Clash Verge Rev와 Mihomo를 사용한 한 macOS 조사에서는 프록시 노드는 도달 가능했지만, 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을 Clash HTTP/mixed 포트로 바꾸세요:

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’s DNS JSON interface를 사용합니다. 연결 패널을 확인하세요. 명시적인 로컬 프록시는 Clash로의 진입을 보장하지만, 최종 egress는 여전히 Clash 규칙이 결정합니다.

서로 다른 IP 주소만으로는 간섭의 증거가 되지 않습니다. CDN 선택, 캐싱, 주소 패밀리, Fake-IP가 차이를 설명할 수 있습니다. Clash의 Fake-IP 범위에서 나온 합성 주소가 본질적으로 의심스러운 것은 아닙니다. 비정상적인 응답을 잘못된 경로와 실패에 함께 대응시킨 뒤, 다른 검증된 네트워크 경로와 비교하세요. TUN이 활성화되어 있으면 dig @resolver조차 가로채질 수 있으므로, 자동으로 독립적인 상위 upstream 테스트가 되는 것은 아닙니다.

대상 지정된 Clash Verge Rev 향상을 적용하세요

이 템플릿은 Mihomo가 포함된 Clash Verge Rev, 기존 구독, 그리고 작동하는 프록시 노드를 필요로 합니다. 이는 완전한 독립형 프로필이 아니라 구독 Script입니다. 먼저 현재 구성을 백업하세요. 이미 Script를 사용 중이라면, 변경 사항을 기존 main(config) 함수에 통합하세요. 모든 향상 단계가 끝난 뒤 최종 런타임 구성을 확인하세요. Clash Verge Rev Script documentation

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을 별도로 확인하기

시스템 프록시를 사용하지 않는 프로세스의 경우 Clash Verge Rev에서 TUN을 활성화하고 실행 중인지 확인하세요. 기존 TUN 객체에 다음 필드를 병합하되, 다른 설정은 유지하세요:

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

이 설정은 포트 53에서 UDP 및 TCP DNS를 다룹니다. Mihomo 문서는 macOS 및 Windows에서 LAN 대상으로 지정된 DNS의 제한을 설명합니다. 애플리케이션이 관리하는 암호화된 DNS 역시 이러한 포트 53 규칙의 범위 밖입니다. 토글이 모든 요청을 포괄한다고 가정하지 말고 리졸버와 인터페이스 동작을 확인하세요. TUN reference

구성, 라우팅, Codex를 별도로 확인하기

먼저 최종 구성에서 오류, 그룹 참조, 규칙 순서를 확인하세요. Mihomo CLI를 사용할 수 있다면 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로 바꾸면 충분한가요?

반드시 그렇지는 않습니다. 리졸버 주소만으로는 암호화, 프록시 라우팅, 도달 가능성을 보장하지 않습니다. 리졸버, 전송, egress를 함께 확인하세요.

Clash가 실행 중인데 왜 Codex가 실패하나요?

프로세스가 프록시를 우회하거나, direct 규칙과 일치하거나, 사용할 수 없는 node DNS에 의존할 수 있습니다. 문제는 DNS와 무관할 수도 있습니다. 여러 설정을 한꺼번에 바꾸기 전에 실제 연결 지점을 찾으세요.

그래도 계속 연결이 끊긴다면?

DNS, TLS, 라우팅이 동작한다면 서비스 상태, 대화 크기, 클라이언트 버전, 노드 연결 안정성, 그리고 정확한 오류 본문을 조사하세요. OpenAI는 피드백과 로그 위치를 문서화합니다. 공유하기 전에 로그에 비밀 정보가 없는지 검토하세요. Troubleshooting and logs

변경 사항은 어떻게 되돌리나요?

추가된 Script를 비활성화하고, 백업해 둔 프로필, TUN 설정, 그리고 변경한 시스템 DNS 설정을 복원하세요. 별도의 proxy-providers 구조를 사용하면 나중에 노드 구독을 로컬 DNS와 규칙에서 분리할 수 있지만, 이 대상 수정에 필수는 아닙니다.

설치 및 가져오기 단계는 Clash Verge setup을 참조하세요. 다른 실패의 경우 Clash troubleshooting을 참조하세요. 이 진단 절차는 이미 호환되는 구독이 있는 경우에 사용할 수 있으며, DNS 테스트를 위해 다른 서비스를 구매할 필요는 없습니다.