OpenAI Codex와 o3 웹·API가 동시에 불안정할 때, 2026년 Clash 분류로 잡기

왜 Codex·o3는 “한 제품”처럼 네트워크를 씁니까

브라우저만 쓰는 대화형 AI와 달리, OpenAI Codex는 터미널·VS Code 계열·원격 에이전트까지 포함해 동일 계정·동일 인프라에 붙는 경우가 많습니다. o3 같은 추론 모델은 응답 지연이 길고 스트림이 오래 열려 있어, 중간에 출구 IP나 경로가 바뀌면 조용히 끊기거나 클라이언트가 긴 재시도 루프에 들어갑니다.

• 웹: chatgpt.com·로그인·세션 쿠키·실험적 UI 플래그.
• API: api.openai.com 등 REST·스트리밍 엔드포인트, 키·조직 단위 라우팅.
• 정적·CDN: 스크립트 번들, 아이콘, 업로드·다운로드가 걸린 스토리지 호스트.
• 장시간 연결: 추론 중 이벤트 스트림, 하트비트, 중간 취소 요청이 같은 TCP·TLS 세션에 얽힘.

한 줄 MATCH,PROXY로 모두내도 “된다”는 경우가 있지만, 대용량 다운로드 노드와 저지연 스트리밍이 같은 정책 그룹에서 경쟁하면 API만 간헐적으로 타임아웃 나는 패턴이 생깁니다. Clash의 이점은 목적별 정책 그룹을 두고 규칙으로 묶는 것입니다.

1단계: chatgpt.com과 API·부가 호스트를 규칙으로 분리

실제 프로필은 구독·원격 규칙 세트에 따라 다르지만, 사고의 뼈대는 같습니다. 브라우저 세션이 기대하는 호스트와 CLI·IDE 플러그인이 치는 호스트가 완전히 같지 않을 수 있으므로, Connections 로그에 찍힌 도메인을 기준으로 행을 만듭니다.

아래는 설명용 YAML입니다. AI-DEV·AI-WEB는 실제 구독의 proxy-group 이름으로 바꾸고, 운영 환경에서 캡처한 호스트로 보강하세요.

# Illustrative rules — verify hostnames in your connection logs
# Put more specific hostnames before broader DOMAIN-SUFFIX (api is under openai.com)
rules:
  - DOMAIN-SUFFIX,api.openai.com,AI-DEV
  - DOMAIN-SUFFIX,chatgpt.com,AI-WEB
  - DOMAIN-SUFFIX,openai.com,AI-WEB
  - DOMAIN-KEYWORD,openai,AI-DEV
  - MATCH,DIRECT

DOMAIN-KEYWORD는 과매칭 위험이 있어 마지막 수단으로 두는 편이 안전합니다. 원격 RULE-SET을 쓰면 OpenAI 관련 행이 이미 들어 있을 수 있으니, 로컬 오버라이드가 위쪽에 남는지 병합 순서를 확인하세요.

2단계: CDN·대용량 전송과 “긴 추론 스트림”을 같은 노드에 두지 않기

o3처럼 생각 시간이 긴 모델은 사용자 체감상 “페이지가 멈췄다”가 아니라 한 줄이 오래 비는 형태로 나타납니다. 이때 네트워크 측에서는 유휴 타임아웃이나 중간 프록시의 버퍼 정책이 관건입니다. 반면 같은 세션 전후로 큰 자바스크립트 번들이나 첨부 업로드가 붙으면, 대역폭을 잡아먹는 쪽이 스트림 패킷을 밀어낼 수 있습니다.

트래픽 유형	노드에 바라는 성질	흔한 실수
API·SSE 스트림	안정 RTT, 긴 세션 유지	스피드테스트만 강한 DC 노드에 무작정 배정
정적 CDN	처리량, 캐시 친화	API와 동일 그룹에서 큐 점유
브라우저 UI	다수 병렬 TLS, 쿠키 일관성	출구 IP가 잦게 바뀌는 자동 선택

정책 그룹을 둘 이상으로 쪼갠 뒤, URL-TEST·FALLBACK의 간격과 타임아웃을 API 쪽은 보수적으로 잡는 방법이 있습니다. “끊기면 즉시 다른 노드”가 스트리밍에는 오히려 독이 될 수 있어, 한 작업 동안 출구를 고정하는 식의 운용도 고려할 만합니다.

3단계: DNS·fake-ip를 API 클라이언트와 맞추기

터미널의 Codex CLI, 언어 런타임의 HTTP 클라이언트, OS 브라우저가 서로 다른 리졸버를 쓰면 같은 이름도 다른 애니캐스트 POP으로 갈라집니다. Clash에서 fake-ip를 쓰는 경우, 일부 스택은 예상과 다른 경로로 붙어 TLS 핸드셰이크는 성공했는데 중간에 RST 같은 증상이 납니다.

• 한 번에 한 변수: 노드를 바꾸기 전에 DNS 모드를 고정하고 재현해 보세요. 자세한 점검 순서는 DNS·fake-ip 가이드를 참고하면 됩니다.
• IPv6: AAAA가 우선되면 의도와 다른 경로로 나가는 경우가 있습니다. 환경에 따라 비활성화나 규칙 정렬을 검토하세요.
• 분할 DNS: 회사 VPN·제로트러스트와 병행할 때는 “어떤 인터페이스가 우선인지”가 OpenAI 호스트에도 그대로 적용됩니다.

4단계: 노드 선택 — “빠름”과 “끊김 없음”은 다른 지표

개발자용 출구는 지연 숫자만이 아니라 패킷 손실·지터·세션 지속 시간이 중요합니다. Codex가 리포지토리 단위로 도구를 호출하는 시나리오에서는 짧은 HTTP가 연속으로 이어지므로, 스트리밍과 유사하게 중간 노드의 큐잉에 민감합니다.

• 전용 그룹: AI-DEV는 가능하면 범용 스트리밍·토렌트와 분리합니다.
• 헬스 체크 URL: 범용 사이트 대신 API 베이스에 가까운 대상을 쓰면 의미가 분명해집니다(정책·약관 범위 내에서).
• 플랩 방지: 지연 테스트 주기가 너무 짧으면 출구가 바뀌며 쿠키·세션이 흔들릴 수 있습니다.

Windows에서 시스템 프록시만으로는 CLI가 빠지는 경우가 많습니다. TUN·터널 모드를 쓰는지, 터미널에 HTTP_PROXY를 줄지는 OS별로 다르며, Cursor·AI 개발 글에서 다룬 “앱이 프록시를 무시하는 문제”와 같은 계열입니다.

Cursor·ChatGPT 글과의 차이 — 이 글의 초점

Cursor 가이드는 특정 IDE와 확장 생태계에 맞춘 편이고, ChatGPT·Grok 글은 범용 채팅 UI에 가깝습니다. 여기서는 OpenAI Codex + o3가 만드는 웹·CLI·API 동시 사용을 한 덩어리로 보고, 호스트 축을 쪼개 정책 그룹에 매핑하는 데 무게를 둡니다. Microsoft Copilot·Claude 등 다른 벤더 글과도 제품 스택이 다르므로, 규칙을 복붙하기보다 로그 기반으로 같은 패턴을 이식하세요.

증상별로 의심할 순서

브라우저는 되는데 CLI·플러그인만 타임아웃

프록시 환경 변수 미적용, DNS 경로 불일치, 또는 API 호스트만 다른 규칙에 걸려 DIRECT로 막힌 경우가 많습니다. Connections에서 해당 프로세스의 목적지를 확인하세요.

추론 중간에 스트림만 끊김

중간 프록시 타임아웃, 노드 플랩, 무선 끊김을 의심합니다. 동일 작업을 유선·다른 그룹으로 재현해 보세요.

로그인·토큰 갱신이 잦아짐

출구 IP가 자주 바뀌거나, 웹과 API가 서로 다른 국가 엣지로 풀리면 리스크 기반 단계가 늘 수 있습니다. 가능하면 한 세션 동안 출구를 안정화합니다.

실무 체크리스트

정리

2026년 OpenAI Codex와 o3는 “채팅 한 줄”이 아니라 도구·브라우저·API가 엮인 작업 파이프입니다. Clash로 분류 규칙과 DNS·노드를 정렬하면, 단순히 “ChatGPT가 느리다”는 말로 포장되기 쉬운 문제를 호스트·세션 단위로 분해해 해결할 수 있습니다.

Clash를 무료로 내려받고 차이를 경험해 보세요