ChatGPT 안 됨·OpenAI API 오류? Clash 고정 노드 분류

증상: ChatGPT가 「안 열리거나」 API만 자꾸 실패할 때

ChatGPT를 브라우저나 공식 앱에서 쓰다 보면, 페이지는 뜨다가 새로고침 직후에만 빈 화면이 되거나 로그인 단계에서 반복된다고 느끼는 날이 있습니다. 개발자나 스크립트 입장에서는 OpenAI API 호출이 간헐적으로 끊기거나, 응답 전에 다른 오류 코드로 바뀌는 패턴이 더 골치 아픈 경우도 있습니다. 둘 다 「서버가 죽었다」만의 문제가 아니라, 클라이언트 측에서 출구 IP가 요청마다 달라지거나, 웹 쿠키와 API 키가 기대하는 네트워크 경로와 어긋나면서 생기는 경우가 2026년에도 흔합니다.

Clash 같은 프록시를 쓰는 환경에서는 특히 그렇습니다. 지연 자체는 나쁘지 않은데, 정책 그룹이 요청마다 다른 노드를 고르면 동일 사용자라도 겉으로는 고정 노드를 쓰는 것처럼 보이지 않습니다. 일부 상용 서비스는 세션·리스크 신호를 출구 IP 기준으로 묶기 때문에, Clash 분류 한 줄과 정책 그룹 모드가 곧 「정상」과 「간헐적 이상」의 차이로 이어질 수 있습니다. 먼저 할 일은 감으로 노드를 바꾸는 것이 아니라, 연결 로그에서 어떤 호스트가 어떤 규칙에 걸렸는지 확인하는 것입니다.

웹 ChatGPT와 OpenAI API는 다른 길을 뺍니다

사용자에게는 모두 OpenAI 생태계로 보이지만, 실제로는 openai.com·chatgpt.com·계정·결제·정적 자산을 나누는 호스트와, api.openai.com을 비롯한 OpenAI API 전용 호스트가 동시에 등장합니다. 앱 업데이트나 Region 설정에 따라 이름이 바뀌거나 늘어날 수 있으므로, 여기서 중요한 것은 암기가 아니라 로그에 찍힌 실제 목적지를 YAML 규칙에 반영하는 습관입니다.

브라우저만 시스템 프록시를 따르고, 터미널의 Python·Node·curl은 프록시를 모른 채 직접 나가면, 화면은 되는데 스크립트만 실패하는 전형적인 분리가 생깁니다. 이때는 TUN 모드로 전체 트래픽을 같은 Clash 분류 아래로 모으거나, 해당 셸에서만 HTTPS_PROXY를 로컬 포트에 맞추는 식으로 출구를 통일하는 편이 안전합니다. IDE 중심으로 정리한 Cursor·Copilot 가이드와 겹치는 부분은 있지만, 본문은 호스트 이름과 도메인 분류를 OpenAI 쪽에 맞추는 데 초점을 둡니다.

규칙에 올릴 도메인 묶음(원칙)

배포판·Rule Provider에 따라 표기는 다르지만, 실무에서는 보통 DOMAIN-SUFFIX로 상위 도메인을 잡고, 로그에만 나오는 예외 호스트를 점진적으로 추가합니다. 예시는 구조 이해용이며, 실제 프로덕션 이름은 반드시 본인 환경의 연결 기록을 따르세요.

# Keep OpenAI-related rules above broad GEOIP / direct rules.
rules:
  - DOMAIN-SUFFIX,openai.com,PROXY_OPENAI
  - DOMAIN-SUFFIX,chatgpt.com,PROXY_OPENAI
  - DOMAIN-SUFFIX,oaistatic.com,PROXY_OPENAI
  - DOMAIN-SUFFIX,openaiapi-site.azureedge.net,PROXY_OPENAI
  # Add api.* and auth-related hosts from your connection logs
  - DOMAIN,api.openai.com,PROXY_OPENAI
  # ... then GEOIP, MATCH, etc.

핵심은 규칙 순서입니다. 넓은 GEOIP나 국내 DIRECT가 먼저 매칭되면, 일부 하위 호스트만 의도와 다른 출구로 새어 나갈 수 있습니다. 스플릿 라우팅의 뼈대는 분류 규칙 최적화에서 다룬 것과 같으며, 여기서는 그 위에 「OpenAI 전용」 정책 그룹을 두는 그림으로 이해하면 됩니다.

고정 노드가 세션·API 키 이상과 맞닿는 이유

자동 선택·지연 기반 Fallback·부하 분산형 그룹은 편하지만, OpenAI API처럼 장시간 스트리밍과 연속 요청이 이어지는 워크로드에서는 출구가 바뀌는 것만으로도 체감 문제가 됩니다. 로그에서 매 요청마다 프록시 이름이 바뀐다면, 품질 문제가 아니라 정책 그룹 모드 자체를 의심할 만합니다.

대응은 단순합니다. 해당 트래픽만 보내는 그룹에서 하나의 노드를 수동 선택하거나, 자동 전환을 끄고 안정적인 출구를 유지합니다. 목표는 「특정 벤더의 이름을 쓰라」가 아니라, 한 작업 세션 안에서 동일 출구 IP를 가능한 한 유지하는 것입니다. 노드를 자주 바꿀수록 쿠키·세션·키 검증이 엇나갈 여지가 커지고, 사용자는 이를 ChatGPT 안 됨이나 API 메시지 한 줄로만 보게 됩니다.

DNS·fake-ip: 이름이 같아도 경로가 다르면 규칙이 흔들린다

브라우저는 Secure DNS와 자체 캐시 정책이 있고, CLI는 시스템 resolver를 탈 수 있습니다. Clash에서 fake-ip를 쓰는데 다른 앱이 먼저 다른 DNS로 응답을 받으면, 규칙 매칭과 실제 소켓이 어긋날 수 있습니다. fake-ip와 redir-host 글에서 설명한 것처럼, 증상이 DNS 쪽이면 모드·필터·캐시를 한 번에 하나씩만 바꿔 변수를 분리하는 편이 낫습니다.

정리하면, api.openai.com을 YAML에 넣었어도 DNS 질의 경로가 갈라지면 결과가 달라집니다. 가능하면 한 프로필 안에서 시스템 DNS·TUN·시스템 프록시 관계를 단순하게 유지하세요.

Claude 편 글과 무엇이 다른가

같은 「생성형 AI + Clash」 주제라도, Anthropic 쪽은 TLS·SNI·장시간 연결 해석이 앞에 서는 경우가 많습니다. OpenAI 쪽은 공개 문서·SDK·웹앱이 넓게 퍼져 있어, 도메인 분류와 고정 노드를 통해 출구 IP 점프를 줄이는 편이 우선인 경우가 많습니다. 흐름 비교를 원하면 Claude 웹·API와 SNI 점검 글을 함께 보시면, 중복 없이 상호 보완이 됩니다.

점검 체크리스트(순서대로)

실패한 요청의 목적지 호스트와 매칭된 정책 그룹을 로그에서 확인합니다.
openai.com·api.openai.com 등이 의도한 그룹으로 가는지 규칙 순서를 YAML과 대조합니다.
자동 전환 그룹을 쓰는 경우, 세션 중 노드 이름이 바뀌지 않는지 확인하고 필요 시 수동 고정합니다.
웹과 API·CLI를 오갈 때 프록시 적용 경로(TUN·환경 변수)를 통일합니다.
DNS 모드·캐시를 점검하고, 문제 재현 시 한 번에 한 설정만 바꿉니다.

보안·정책에 대한 짧은 메모

회사 기기·교육망에서는 프록시·TUN 설치 자체가 허용되지 않을 수 있습니다. 본문은 연결 안정성에 대한 기술 설명이며, 특정 서비스를 사용하라는 뜻이나 약관·법률 검토를 대신하지 않습니다. 각 환경의 정책과 OpenAI 이용 약관을 우선하세요.

정리

ChatGPT가 열리지 않거나 OpenAI API만 불안정할 때, 범용 「해외 프록시」 규칙만으로는 부족하고 실제 호스트와 정책 그룹의 매칭을 로그로 확인해야 합니다. openai.com과 api.openai.com을 같은 그룹으로 묶되, 앞선 규칙 순서와 고정 노드로 출구를 안정화하면 IP 점프로 인한 세션·키 이상을 줄이는 데 도움이 됩니다.

클라이언트 설치 경로가 여러 갈래로 흩어져 있어 혼동하기 쉬우니, 실행 파일과 구독 구성을 한곳에서 정리하고 싶다면 ClashFast 다운로드 페이지를 참고하세요. 환경을 맞춘 뒤에는 → Clash를 무료로 내려받아 분류 규칙과 고정 노드를 직접 조합해 보세요.