1. 증상부터 맞추기: 느림과 불일치는 다릅니다
사용자들은 흔히 “노드가 나쁘다”고 말하지만, 실제 관찰에서는 일부 리소스만 실패하는 패턴이 더 많습니다. 스타일시트 서버는 직결되는데 API 만 우회한다든지, 인증 도메인만 다른 정책 그룹에 걸린다든지 하는 경우입니다. Clash 연결 로그에 표시되는 정책 이름과 브라우저 개발자 도구의 호스트 목록을 나란히 놓으면 원인이 금방 좁혀집니다.
구독 링크를 YAML 로 가져오는 절차가 익숙하지 않다면 구독 가져오기 튜토리얼을 먼저 보고 오세요.
2. 권장 점검 순서
- Clash 실행 여부와 시스템 프록시 또는 TUN 사용 여부를 기록합니다.
- 실시간 연결 목록에서 OpenAI 관련 호스트가 기대한 정책 그룹으로 나가는지,
DIRECT로 새는지 봅니다. fake-ip를 쓰는지 확인하고, 필요하면 특정 접미사에nameserver-policy를 지정합니다.- 메인 사이트·정적 자산·API 를 호스트 단위로 규칙에 올리고, 공급자 규칙과 순서가 충돌하지 않게 정리합니다.
- 규칙이 맞다는 전제에서 API 용으로 지터가 적은 노드를 고르고 과도한 자동 페일오버를 줄입니다.
일반적인 오류 코드와 복구 절차는 Clash 일반 트러블슈팅 가이드를 참고하세요.
3. 시스템 프록시와 TUN: 앱이 따로 노는 이유
OS 가 제공하는 프록시 설정은 편리하지만, 시스템 프록시를 무시하는 런타임이 분명히 존재합니다. 일부 터미널 도구, 컨테이너 내부 프로세스, 샌드박스형 앱이 대표적입니다. 그 결과 브라우저의 ChatGPT 는 정상인데 curl 로 api.openai.com 을 찍으면 실패하는 상황이 생깁니다.
TUN 은 라우팅 계층에서 잡아 주기 때문에 일관성은 좋아지지만, 어댑터 권한과 다른 VPN 과의 충돌 같은 변수가 늘어납니다. TUN 모드 안내를 따라 켠 뒤, 다시 연결 로그로 OpenAI 트래픽이 모두 Clash 를 통과하는지 확인하세요.
4. DNS·fake-ip: 작은 어긋남이 큰 스피너로
fake-ip 는 체감 속도에 도움이 될 수 있으나, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 재시도가 늘고 SPA 는 끝없이 로딩처럼 보입니다. 서브도메인과 CDN 이 많은 서비스일수록 증상이 크게 드러납니다.
먼저 상위 DNS 가 신뢰 가능하고 도달 가능한지 확인하고, 이어서 openai.com, chatgpt.com, oaistatic.com, oaiusercontent.com 등 핵심 접미사에 별도 정책을 두어 흔들림을 줄이세요. 필드 이름은 코어 버전에 따라 다를 수 있으니 Mihomo 문서를 함께 보세요.
5. 웹과 API 호스트를 의도적으로 분리
하나의 넓은 규칙으로 끝내고 싶은 유혹이 있지만, 공급자가 넣은 광범위한 직결 규칙이나 브라우저 확장의 예외가 끼어들면 일부 호스트만 다른 길로 새기 쉽습니다. 아래 표는 점검용 체크리스트이며, 실제 이름은 개발자 도구로 검증해야 합니다.
| 구분 | 예시 방향 | 팁 |
|---|---|---|
| 채팅 UI | chatgpt.com, chat.openai.com | 인증·정적 자산과 규칙 순서를 맞춥니다. |
| 콘솔 | platform.openai.com | 과금·문서 API 와 묶을지 분리할지 선택합니다. |
| API | api.openai.com | 안정적인 지연을 우선하고 노드 자동 전환을 과하게 두지 않습니다. |
| 정적 | oaistatic.com 등 | 누락 시 화면이 반쯤 비어 보입니다. |
6. 규칙 예시 (그룹 이름은 교체)
# Example only — replace PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,openai.com,PROXY
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,oaistatic.com,PROXY
- DOMAIN-SUFFIX,oaiusercontent.com,PROXY
- DOMAIN-KEYWORD,openai,PROXYAPI 만 별도 그룹으로 빼려면 DOMAIN,api.openai.com,PROXY_API 처럼 명시하고, 웹은 PROXY_WEB 에 두면 디버깅이 쉬워집니다.
7. 노드 전략: 순간 속도보다 안정성
벤치마크 상위 노드라도 짧은 구간에서 지터가 크면 HTTP/2 세션이 자주 갈아타며 API 오류로 이어집니다. OpenAI 규칙에는 손실이 적은 회선을 고정하거나, 자동 페일오버 임계값을 완화하는 편이 낫습니다. 전송 프로토콜 특성은 프로토콜 비교 글에서 보조 근거를 얻을 수 있습니다.
8. GUI 워크플로: Clash Verge Rev
연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾습니다. 첫 설치와 구독 흐름은 초보자 가이드를 따르세요.
9. 추가 함정: 확장 프로그램과 이중 VPN
브라우저 확장이 자체 프록시를 켜 두면 OS 설정과 겹쳐 혼란을 키웁니다. 점검 시에는 잠시 끄세요. Clash 외 다른 상시 VPN 과 동시에 켜면 루프나 이중 터널처럼 보이는 증상이 납니다. 한 번에 하나의 출구만 남기고 다시 테스트하세요.
자동화 파이프라인을 쓰는 팀이라면 CI 러너나 원격 셸 환경에도 동일한 프록시 변수가 전달되는지 문서로 남겨 두세요. 노트북에서는 잘 되는데 서버 작업만 실패하는 경우, 대개 그 환경이 macOS 나 Windows 시스템 프록시를 읽지 않기 때문입니다. 이럴 때 TUN 이나 컨테이너 단의 명시적 프록시 환경 변수를 표준으로 정하면 재현하기 어려운 “가끔 실패”를 크게 줄일 수 있습니다.
10. 정리: 증거를 한 층씩 쌓기
ChatGPT 나 OpenAI 콘솔 문제는 단일 스위치가 아니라 모드·DNS·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. 이 글의 순서대로 로그 근거를 남기면 불필요한 노드 순환을 줄일 수 있습니다. 프로토콜 비교나 일반 오류 모음과 겹치지 않는, 생성 AI 트래픽 전용 분류 노트로 쓰시길 바랍니다.
YAML 을 매번 손으로 다듬기보다 Mihomo 가 내장된 공식 클라이언트에서 로그와 업데이트를 한곳에 모으는 편이 더 편할 때도 많습니다. → Clash 를 무료로 내려받고 차이를 직접 확인해 보세요