1. 증상을 네 가지 축으로 나누기
첫째, 브라우저의 OpenAI 콘솔이나 문서 페이지는 열리는데 확장 프로그램만 “업데이트 확인 중”에서 멈추는 경우는 정적 자산·업데이트 매니페스트·서명 검증 호스트가 다른 출구로 갈라진 패턴을 의심합니다. 둘째, 에디터 안 Codex 패널은 뜨는데 명령 한 번마다 곧바로 끊기거나 재연결 배너가 반복되는 경우는 장시간 HTTPS·WebSocket에 가까운 세션이 노드 품질이나 중간 장비의 유휴 타임아웃과 맞물린 경우가 많습니다. 셋째, 로컬 스크립트나 CI에서만 API 도메인 요청이 간헐적으로 실패하는 경우는 터미널 프로세스가 시스템 프록시를 덜 따르거나, curl만 직결로 나가는 등 개발자 프록시 경로가 IDE와 다른 케이스입니다. 넷째, 노드를 바꾸면 즉시 나아지는 경우는 규칙보다 해당 노드의 UDP·장시간 연결 허용 여부를 우선 의심하세요. 이후 단계에서는 이 네 축을 번갈아 재현하며 로그에 어떤 호스트가 붙는지 메모하는 습관이 중요합니다.
공항 프로필이 아직 불안정하면 구독 가져오기 튜토리얼에서 규칙 병합 순서를 정리한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.
2. 왜 콘솔과 API를 한 번에 묶으면 깨질까
OpenAI Codex는 단일 도메인 앱이 아니라, 인증·과금·조직 정책과 맞닿은 OpenAI 콘솔 축, 패키지·아이콘·문서 CDN에 가까운 정적 축, 그리고 api.openai.com을 포함한 API 도메인 축이 한 워크플로 안에서 동시에 열립니다. 공항 구독에 DOMAIN-KEYWORD,openai 한 줄로 끝내기 쉽지만, 실제로는 CDN 엣지가 GEOIP 규칙에 의해 의도치 않게 DIRECT로 빠지거나, 반대로 API만 다른 정책 그룹에 묶여 지연이 달라지는 일이 생깁니다. “전부 같은 노드”로 보이게 두었는데도 증상이 남는 이유는 Clash가 보여 주는 정책 결과와 사용자의 머릿속 모델이 어긋나 있기 때문입니다. 먼저 도덕적 판단이 아니라 연결 로그에 기록된 출구를 확인하세요.
3. 권장 점검 순서: 모드 → 로그 → DNS → 규칙
- Clash가 시스템 프록시만인지 TUN까지 켰는지 기록합니다. Electron 기반 에디터·별도 CLI가 시스템 프록시를 무시하면 출구가 갈라집니다.
- 연결 패널을 연 상태에서 콘솔 로그인, Codex 패널에서 짧은 질의, 로컬에서 소량 API 호출을 각각 수행합니다.
- 로그에 나타난
openai.com·chatgpt.com·oaistatic.com·cdn.openai.com등 후보와api.openai.com행을 정책 이름과 함께 적어 둡니다. fake-ip사용 여부와 DNS 해석 경로를 확인하고, 같은 호스트에서 TLS 핸드셰이크가 반복되는지 봅니다.- 필요하면
DOMAIN-SUFFIX블록을 규칙 상단에 올리고, 광범위GEOIP·DIRECT와의 충돌을 정리합니다. - 규칙이 맞는데도 장시간 세션만 끊기면 노드 측 유휴 제한·MTU·UDP를 추가로 확인합니다.
4. 콘솔·정적 자산·API 도메인의 역할 차이
OpenAI 콘솔은 조직·API 키·사용량 같은 메타데이터를 주고받는 HTTPS 세션이 중심입니다. 문서 페이지와 마케팅 도메인은 캐시 친화적인 정적 자산 비중이 높고, 실시간 코딩 보조에 가까운 흐름은 API 도메인과 에디터 확장의 백그라운드 채널이 나눠 갖습니다. 한쪽만 느리면 “노드 ping은 낮은데 왜 Codex만 끊기지?”라는 말이 나오는데, ping이 재는 경로와 브라우저가 여는 호스트 묶음이 다를 수 있습니다. Clash 분류에서는 이 층을 의도적으로 나누되, 개발자 프록시 운영 관점에서는 “인증·API·장시간 스트림”이 서로 다른 국가 엣지로 흩어지지 않도록 한 정책 그룹으로 묶는 A/B 테스트를 권장합니다.
5. IDE·CLI가 프록시를 타는 경로
VS Code·Cursor·JetBrains 계열은 각각 HTTP 프록시 환경 변수와 앱 내 설정을 다룹니다. Codex 확장이 “마켓플레이스는 되는데 패널만 실패한다”면 마켓과 본 세션이 다른 프로세스·다른 프록시 테이블을 쓰는지 의심하세요. 이때 TUN 모드를 켜면 라우팅 계층에서 잡혀 동일 출구로 묶이기 쉽습니다. macOS·Linux 터미널만 직결이면 터미널 프록시 환경 변수 글에서 HTTPS_PROXY 일관성을 먼저 맞추고 돌아오세요. Windows에서 Microsoft Store·루프백 이슈가 겹치면 UWP·Store 글과 교차해 보는 것도 도움이 됩니다.
6. DNS와 fake-ip: 이름이 틀어지면 콘솔만 느리다
fake-ip는 체감 지연을 줄일 수 있지만, 규칙 엔진에 넘기는 이름과 실제 백엔드가 어긋나면 TLS 재시도가 반복됩니다. OpenAI 측은 지역 엣지와 리다이렉트가 많아 작은 어긋남도 “페이지는 열리는데 패널만 스피너”로 보입니다. 상위 DNS가 신뢰 가능하고 Clash에서 도달 가능한지 먼저 확인한 뒤, 로그에 반복되는 접미사에 전용 해석 정책을 두는 방식을 검토하세요. 규칙을 고친 뒤에는 브라우저 프로필·에디터를 완전히 종료했다가 다시 열어 이전 세션을 걷어내는 것도 도움이 됩니다.
7. 도메인 수집: 로그로 Codex 전용 묶음 만들기
인터넷에 떠도는 “완성된 OpenAI 도메인 목록”은 배포 시점에 따라 빠르게 달라질 수 있습니다. Clash Verge Rev 등 GUI의 연결 보기를 연 뒤 Codex에서 동일 시나리오를 두 번 반복하고, 새로 뜬 행만 시간순으로 적으면 어떤 동작이 어떤 호스트 묶음을 깨우는지 대응표가 생깁니다. 로그인 직후에만 보이는 인증 호스트, 패널 질의 직후에만 보이는 API 도메인 행, 업데이트 직전에만 보이는 릴리스·서명 관련 호스트를 구분하세요. 실패한 연결(타임아웃·RST) 행을 우선 규칙에 올리면 체감 개선이 큽니다. 개발자 프록시 운영에서는 “노드만 바꾸기”보다 로그 문자열을 그대로 복사해 규칙에 반영하는 습관이 더 빠릅니다.
8. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름은 반드시 연결 로그로 검증해야 합니다.
| 구분 | 예시 패턴 | 메모 |
|---|---|---|
| 콘솔·계정 | platform.openai.com·auth.openai.com 계열 | 로그인 루프·조직 전환과 함께 움직이는지 확인합니다. |
| 정적·문서 | oaistatic.com·CDN 접미사 | 아이콘·번들이 느릴 때 이 층만 다른 노드로 가는지 봅니다. |
| REST·배치 API | api.openai.com | 스크립트·CI와 IDE가 같은 출구를 쓰는지 대조합니다. |
| 장시간 세션 | 패널 질의 직후 길게 유지되는 호스트 | 유휴 타임아웃이 의심되면 노드 교체 실험을 병행합니다. |
| 업데이트·서명 | 릴리스 메타·코드 서명에 가까운 호스트 | “확장만 오래된 버전” 패턴과 함께 봅니다. |
9. 규칙 예시 (정책 그룹 이름은 반드시 교체)
# Example only — replace OPENAI_DEV with your policy group; verify in logs
rules:
- DOMAIN,api.openai.com,OPENAI_DEV
- DOMAIN-SUFFIX,openai.com,OPENAI_DEV
- DOMAIN-SUFFIX,oaistatic.com,OPENAI_DEV
- DOMAIN-SUFFIX,chatgpt.com,OPENAI_DEVDOMAIN-KEYWORD,openai처럼 과하게 넓히면 무관한 트래픽까지 잡힐 수 있으니, 로그에 근거해 접미사를 좁히세요. 먼저 같은 정책 그룹으로 묶여 안정화한 뒤, 필요하면 정적 CDN과 API 도메인을 다른 그룹으로 나누어 실험합니다. 세션 중 출구가 바뀌면 리전 판정이 흔들릴 수 있으니 A/B 테스트는 업무 시간 밖에서 진행하는 편이 안전합니다.
10. 장시간 연결과 타임아웃
Codex류 패널은 짧은 REST 한 방이 아니라 응답이 길게 이어지는 스트림에 가까운 구간이 있습니다. 중간 프록시나 상업 노드가 유휴 TCP를 잘라 버리면 클라이언트는 “끊겼다가 곧바로 재연결” 패턴을 보입니다. 이때는 규칙 순서보다 노드 제약이 원인인 경우가 많습니다. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.
11. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,KR,DIRECT 같은 광범위 규칙이 있으면, 일부 글로벌 CDN 엣지만 의도치 않게 직결로 보내져 “콘솔은 프록시인데 아이콘만 느리다”는 패턴이 납니다. 이럴 때는 OpenAI 관련 블록을 규칙 상단에 두거나, 공급자 규칙 뒤에서도 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요. 구독이 갱신되며 예전에 넣어 둔 로컬 규칙이 아래로 밀리는 경우도 흔합니다. “OpenAI 전용 블록”을 파일 상단 근처에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.
12. GUI 워크플로: Clash Verge Rev
연결 패널에서 openai·oaistatic·api. 문자열을 필터링하면 잘못된 DIRECT를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요.
13. ChatGPT 웹 글과의 차이
ChatGPT·OpenAI 분류 글은 브라우저 중심의 대화 UI와 범용 API 호출을 넓게 다룹니다. 이 글은 OpenAI Codex가 추가로 거는 에디터 확장·데스크톱·콘솔 교차 세션을 전제로, 개발자 프록시에서 흔한 “프로세스마다 출구가 다르다”는 문제를 앞에 둡니다. 규칙 블록을 이름만 바꿔 복사하기보다 본문 7절의 절차대로 Codex 세션 로그를 다시 모으세요.
14. 그래도 안 될 때: 일반 트러블슈팅과의 교차
포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 혼합 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Codex 전용 단계로 돌아오세요.
15. 준수 안내
이 글은 불법 우회나 약관 위반을 돕는 방법이 아니라, 조직이 허용한 범위에서 네트워크 경로를 일관되게 맞추어 품질을 개선하는 데 초점을 둡니다. OpenAI 서비스 약관·데이터 보존·조직 정책은 각사 규정과 최신 약관을 따르세요.
16. 정리: 로그로 콘솔·확장·API 도메인 출구를 한 줄로 맞추기
2026년 OpenAI Codex 도구맥이 넓어질수록 OpenAI 콘솔·정적 자산·에디터 확장·API 도메인이 한 세션 안에서 동시에 열립니다. 국내 회선에서 Clash 분류를 켠 뒤 끊김·업데이트 실패·타임아웃이 난다면 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. 먼저 연결 로그로 각 호스트가 같은 정책 그룹을 보는지 증명하면, 불필요한 노드 순환과 잘못된 DIRECT를 빠르게 줄일 수 있습니다.
설정 파일을 매번 직접 고치기보다 Mihomo를 내장한 공식 클라이언트에서 로그·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash를 무료로 내려받고 Codex·API 도메인 세션을 같은 출구로 묶어 보세요