일반 ChatGPT 대화는 되는데 코딩 에이전트만 자주 끊깁니다. 같은 규칙이면 안 되나요?

대화 한 카드와 코딩 에이전트는 호스트 조합·연결 지속 시간·도구 HTTP 호출 패턴이 달라서 동일 DOMAIN 한 줄로 묶기 어렵습니다. 로그에 새로 뜬 접미사부터 분리해 넣는 편이 안전합니다.

DNS만 바꾸면 해결될 때도 있나요?

회사망이나 공유기가 특정 DoH·DoT를 막거나, fake-ip와 실제 스트리밍 응답이 어긋나면 타임아웃이 증상으로만 보이기도 합니다. 규칙과 DNS를 같은 패널에서 동시에 보는 것이 필요합니다.

호스트 목록을 매번 수집하기 번거롭습니다.

운영용과 테스트용 YAML을 나누고, RULE-PROVIDER로 외부 리스트를 받되 코딩 에이전트 전용 prepend 규칙만 Git으로 고정하면 릴리스마다 바뀌는 최소 접미사만 추적하면 됩니다.

📖 튜토리얼 2026년 5월 11일 ⏱ 약 20분 분량

ChatGPT 속 OpenAI Codex·클라우드 코딩 에이전트가 타임아웃할 때: Clash 분류 규칙과 DNS를 같이 맞추기 (2026)

2026년에는 브라우저에서 곧바로 돌아가는 코딩 에이전트(제품명은 Codex 등으로 표기되는 경우가 많음)가 일반 대화 카드와 다른 호스트 묶음·긴 스트림·도구 호출을 동시에 열기 때문에, 「ChatGPT는 되는데 에이전트만 실패」처럼 보이는 경우가 늘었습니다. 이 글은 OpenAI Codex·ChatGPT·코딩 에이전트·Clash·분류·DNS·타임아웃으로 검색해 들어온 분이 바로 적용할 수 있도록, 일반 접속 가이드와 겹치지 않게 에이전트 세션을 전제로 복붙 가능한 규칙 골격과 실측 순서를 한국어로 정리합니다. 같은 회사망이라도 카드마다 증상이 갈라지는 이유부터 짚습니다.

① 왜 「ChatGPT는 되는데 Codex(코딩 에이전트)만」 끊기기 쉬운가

표면적으로는 모두 OpenAI 계정과 같은 스킨을 쓰지만, 코딩 에이전트는 길게 열린 HTTPS 세션, 간헐적인 대용량 자산, 때로는 외부 저장소·패키지 레지스트리로 이어지는 도구 호출까지 한 번에 겹칩니다. 사용자 입장에선 똑같이 채팅 상자처럼 보여도, 실제 TLS SNI는 api.openai.com에 머무는 요청과 chatgpt.com·chat.openai.com 계열, 그리고 정적 자산·첨부 축인 oaistatic.com·oaiusercontent.com 같은 접미사로 갈라지기 쉽습니다.

그래서 Clash에서 한 줄 DOMAIN-SUFFIX,openai.com만 넣었을 때는 대화형 검색은 통과해도, 에이전트가 추가로 여는 호스트가 GEOIP 또는 말단 MATCH 줄에 더 먼저 걸려 국내 직접 회선으로 나가 버리면 패킷만 반쯤 막힌 것처럼 보입니다. 반대로 전역 프록시를 과하게 켜 두면 결제·계정·내부 SAML 리다이렉트가 꼬여 로그인 루프가 생기기도 해서, 분류라는 말이 여기서 핵심이 됩니다.

전반적인 Rule·모드 개념은 Clash 입문 튜토리얼에서 먼저 정리하고 들어오면 아래 단계의 「이름 표기」가 덜 헷갈립니다.

② 기존 ChatGPT 글과 무엇이 다른지: 검색 의도부터 분리합니다

블로그의 ChatGPT·OpenAI 웹·API 분류 글은 대화 UI와 REST API 축을 동시에 안정화하는 데 초점이 맞춰져 있습니다. 반면 이 글은 제목 그대로 Codex나 이에 준하는 클라우드 코딩 에이전트가 브라우저 세션 안에서 돌 때 생기는 연속 타임아웃·중간에 끊기는 스트림·도구 호출만 실패를 전제로, 호스트를 다시 조각 냅니다. 즉 단순히 「접속된다/안 된다」가 아니라 에이전트 작업 단위로 끊기는지를 복제해야 합니다.

로컬 IDE 쪽 Cursor 3·SDK 파이프라인까지 네트워크가 한 번에 깨질 때는 Cursor 3 + Verge DNS 글이나 Cursor Agent SDK·CI API 분류 글과 짝을 지어 보는 편이 빠릅니다. 지금 글은 그중에서도 ChatGPT 웹에 머무는 코딩 에이전트에 한정합니다.

③ 먼저 증상 문자열을 숫자가 아니라 글자 그대로 고정합니다

추측으로 rules 줄을 넣었다가는 한 달 뒤 제품 업데이트에 바로 깨집니다. 아래 순서를 권장합니다.

브라우저 개발자 도구의 네트워크 탭에서 코딩 에이전트를 실제로 실행하고, 빨간 줄로 끊긴 호스트 문자열을 복사합니다.
동일 시점에 Mihomo·Verge Rev 연결 로그를 열어 같은 초에 찍힌 RULE 결과와 프록시 그룹 이름을 함께 저장합니다.
가능하면 같은 머신에서 curl -v로 대표 호스트에 핸드셰이크 시간을 재어, 규칙 문제인지 회선 자체 지연인지를 나눕니다.

이때 DNS가 한 번은 회사 내부 캐시·다음 번에는 공용 DoH를 타는 패턴이면, 동일 호스트라도 IP가 달라져 규칙 적중이 흔들립니다. fake-ip가 켜져 있다면 fallback과 nameserver 순서가 겹치는지도 같은 표에 적습니다.

💡 한 줄 요약 코딩 에이전트 디버깅에서 가장 비싼 실수는 로그 없이 브랜드 이름만 보고 규칙을 추가하는 일입니다. 실패한 줄의 호스트 문자열이 1순위 증거입니다.

④ 복붙용 규칙 스케치: OPENAI_CODEX 블록을 앞쪽에 둡니다

아래는 개념 예시입니다. OPENAI_CODEX는 본인 YAML의 proxy-groups 이름과 반드시 같아야 하고, MATCH 위쪽·GEOIP,CN,DIRECT와의 상대 순서는 회사 정책에 맞게 조정합니다.

rules:
  - DOMAIN-SUFFIX,api.openai.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,chatgpt.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,chat.openai.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,openai.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,oaistatic.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,oaiusercontent.com,OPENAI_CODEX
  - DOMAIN-SUFFIX,platform.openai.com,OPENAI_CODEX
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

범위를 좁히고 싶다면 openai.com 한 덩어리 대신 로그에 실제로 등장한 접미사만 남기고, 새 이름이 뜰 때마다 위쪽에 덧붙입니다. 문법·중복 규칙은 사용자 정의 규칙 튜토리얼과 교차 검증하세요.

⑤ DNS: fake-ip·DoH·정책 축을 한 화면에서 보기

Clash Meta에서 fake-ip는 편리하지만, 브라우저·에이전트·curl이 서로 다른 해석 경로를 타면 「한 번은 붙고 한 번은 끊김」이 됩니다. 점검 포인트는 세 가지입니다.

nameserver-policy가 특정 접미사만 다른 리졸버로 보내고 있지 않은지.
fallback 필터가 너무 공격적이라 응답이 번갈아 가며 바뀌지 않는지.
회사 Split DNS가 내부 도메인과 외부 OpenAI 호스트를 동시에 가로막지 않는지.

Windows에서 구독 본체는 건드리지 않고 DNS 블록만 덮어씌우려면 Verge Rev Mixin 가이드의 패턴을 응용할 수 있습니다. Mac이나 Linux라도 개념은 동일합니다.

⑥ 시스템 프록시와 TUN: 브라우저 샌드박스가 숨은 통로를 만들 때

일부 브라우저 프로필은 확장·샌드박스가 시스템 프록시를 우회합니다. 그 상태에서 코딩 에이전트만 별도 프로세스로 붙으면 규칙은 맞는데 패킷은 틀린 NIC로 나가는 그림이 됩니다. TUN 모드를 켤 수 있는 환경이라면 한 번에 묶는 편이 재현성이 높습니다. 터널이 둘 이상 겹치면 DNS 출구가 더 중요해지므로 TUN 심화 글의 NIC·DNS 순서 팁을 참고하세요.

⑦ 스트림·도구 호출이 겹칠 때 타임아웃이 도는 전형 패턴

에이전트가 파일을 읽고 요약한 뒤 바로 외부 패키지 페이지를 연다면, 짧은 시간에 새 TCP 연결 수가 급증합니다. 이때 규칙이 맞더라도 노드 레이트 제한·본사 방화벽의 동시 세션 상한에 걸리면 프록시 단에서 응답 지연로 보입니다. 증상을 네트워크·앱·정책으로 나누려면 동일 호스트에 대해 프록시 on/off를 번갈아 로그로만 비교하는 편이 빠릅니다.

Microsoft 쪽 코파일럿류와 도메인이 겹칠 때는 Copilot 분류 글과 헷갈리지 않게, 팀 위키에 「코딩 에이전트 전용 호스트 목록」을 따로 두는 것도 비용이 적습니다.

⑧ 체크리스트: 30분 안에 다시 재현 가능하게 만들기

실패한 호스트 문자열을 이슈 템플릿에 그대로 붙여 넣습니다.
Clash 로그 한 줄(어느 그룹으로 갔는지)을 같은 타임스탬프로 저장합니다.
DNS 응답 A/B: fake-ip on/off 각각에서 한 번씩 재현합니다.
규칙 줄 위치를 옮겨 GEOIP보다 위에 두었는지 확인합니다.
브라우저만 문제면 시스템 프록시·TUN·프로필 초기화 순으로 좁힙니다.

기록이 쌓이면 릴리스마다 바뀌는 최소 접미사만 덧붙이면 되어, 매번 전체 목록을 외울 필요가 없습니다.

⑨ 자주 묻는 질문

ChatGPT 웹 접속 글만 보면 부족한가요?

대화 한 카드만 안정화하는 설정이면 부족할 수 있습니다. 코딩 에이전트는 호스트 조합이 더 길고 스트림이 길어서, 같은 문서라도 에이전트 섹션을 따로 두는 편이 실무에 맞습니다.

모바일 브라우저에서도 같나요?

원칙은 같지만 배터리·백그라운드 정지·데이터 세이버가 끼어 들면 증상이 다르게 보입니다. 가능하면 데스크톱과 동일 로그 포맷으로 먼저 재현한 뒤 옮깁니다.

RULE-SET만 믿어도 되나요?

외부 리스트는 편하지만 릴리스 초기에는 새 접미사가 늦게 들어옵니다. 코딩 에이전트는 prepend 규칙으로 팀이 직접 본 몇 줄을 고정하는 하이브리드가 안전합니다.

⑩ 정리: 코딩 에이전트는 호스트가 곧 기능 단위입니다

제품 이름이 바뀌어도 OpenAI Codex나 이에 준하는 코딩 에이전트가 쓰는 호스트는 문서·CDN·API·첨부로 쉽게 갈라집니다. 이를 한 줄 브랜드 규칙으로 끝내면 대화는 살아도 에이전트만 끊기는 형태가 반복됩니다.

반면 전통적인 종류의 올인원 VPN은 클릭 몇 번으로 모든 트래픽을 한 터널에 넣는 편의가 있지만, 코딩 에이전트처럼 같은 세션 안에서 서로 다른 DNS·자산·API 축을 동시에 두드릴 때는 어떤 호스트가 터널 밖으로 새는지 조용히 묻히기 쉽고, 제한된 회사망에서는 오히려 전체가 느려지기도 합니다. Clash·Mihomo 계열은 규칙을 텍스트와 RULE-PROVIDER로 남겨 팀과 공유하기 쉽고, 로그 한 줄로 「어느 그룹으로 갔는지」를 바로 확인할 수 있어 타임아웃처럼 보이는 증상을 빠르게 원인 축으로 접을 수 있습니다.

위 체크리스트를 한 번 통과한 프로필은 테스트용과 운영용으로 나눠 두면 이후 릴리스 대응 부담이 줄어듭니다. 아직 클라이언트를 고르는 중이라면 Clash 다운로드 페이지에서 환경에 맞는 빌드를 받아, 코딩 에이전트 전용 최소 규칙부터 적용해 보세요.