2026년 ChatGPT·OpenAI 웹과 API를 Clash로 나눠 쓰기: 도메인 규칙·분류·DNS·실측

① 왜 웹 ChatGPT와 OpenAI API는 「한 줄 DOMAIN-SUFFIX」로 끝내기 어렵나

브라우저에서 대화를 열면 HTML·정적 자산·실시간 스트림·계정 흐름이 서로 다른 서브도메인으로 흩어집니다. 반면 REST API나 OpenAI 호환 SDK는 대개 api.openai.com처럼 고정에 가까운 호스트에 직접 붙습니다. 여기에 시스템 프록시를 따르지 않는 프로세스·TUN 미사용·환경 변수 없는 curl까지 겹치면, 사용자 입장에서는 「같은 OpenAI인데 한쪽만 안 된다」로 느껴집니다.

따라서 실무에서는 브랜드 이름보다 TLS SNI에 실제로 찍히는 호스트를 기준으로 규칙을 만드는 편이 안전합니다. 서비스가 바뀌면 CDN·인증·실험 호스트가 추가되기도 하므로, 아래 목록은 출발점이며 확정은 Clash 연결 로그와 브라우저 개발자 도구의 네트워크 탭으로 맞추는 것이 좋습니다.

② 분류 대상: OpenAI·ChatGPT 웹·API·플랫폼에 자주 붙는 도메인 후보

공식 문서에서 안내하는 API 베이스 URL은 통상 https://api.openai.com이며, 경로에 /v1를 붙여 호출하는 예가 많습니다. 웹 챗은 chat.openai.com·chatgpt.com 계열이 중심이 되는 경우가 많고, 마케팅·문서·계정은 openai.com·platform.openai.com 등으로 이어질 수 있습니다. 정적 자산·업로드에는 oaistatic.com·oaiusercontent.com 같은 호스트가 로그에 등장하는 사례도 흔합니다.

• API 트래픽: api.openai.com (문서 기준 대표 엔드포인트)
• 웹 대화·제품 진입: chat.openai.com, chatgpt.com, 필요 시 www.openai.com
• 개발자 플랫폼·키·결제 UI: platform.openai.com, 문서·상태 페이지 등 openai.com 하위 호스트
• 자산·첨부: 로그에 보이는 oaistatic.com, oaiusercontent.com 등 (환경마다 상이)

한 번에 DOMAIN-SUFFIX,openai.com만 넣으면 설정은 단순해지지만 범위가 넓어집니다. 조직 정책상 좁게 가려면 api.openai.com과 웹 챗 호스트부터 넣고, 로그에 새 이름이 뜰 때마다 덧붙이는 방식이 스플릿 라우팅 의도에 잘 맞습니다. 문법이 처음이면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 익히면 실수가 줄어듭니다.

③ 최소 규칙 예시: OpenAI 계열만 PROXY, 나머지는 DIRECT

아래는 개념 YAML입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 본인 환경(국내 트래픽 DIRECT 등)에 맞게 조정하세요.

rules:
  # OpenAI / ChatGPT — verify hosts in client logs after product updates
  - DOMAIN-SUFFIX,api.openai.com,PROXY
  - DOMAIN-SUFFIX,chat.openai.com,PROXY
  - DOMAIN-SUFFIX,chatgpt.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-SUFFIX,oaistatic.com,PROXY
  - DOMAIN-SUFFIX,oaiusercontent.com,PROXY
  - MATCH,DIRECT

openai.com 한 줄이 플랫폼·문서까지 넓게 덮는 대신, 의도하지 않은 하위 서비스까지 같은 출구로 갈 수 있습니다. 반대로 API만 분리하고 싶다면 api.openai.com만 먼저 두고 웹 호스트를 로그 기반으로 추가해 나가면 됩니다. 아무 것도 붙지 않을 때는 잠시 MATCH,PROXY로 바꿔 터널 자체가 정상인지부터 가르는 것도 좋은 디버깅 순서입니다.

④ 웹과 API를 다른 노드로 보내고 싶을 때: 프록시 그룹 두 개

지연·안정성 때문에 브라우저 챗과 배치 API에 서로 다른 출구를 쓰고 싶다면 그룹을 나눠 규칙에서 이름만 바꿉니다. 예시는 구조 이해용이며, 실제 노드 목록은 본인 구독에 맞게 바꿉니다.

proxy-groups:
  - name: OPENAI_API
    type: select
    proxies: [🚀 자동 선택, DIRECT]
  - name: OPENAI_WEB
    type: select
    proxies: [🚀 자동 선택, DIRECT]

rules:
  - DOMAIN-SUFFIX,api.openai.com,OPENAI_API
  - DOMAIN-SUFFIX,platform.openai.com,OPENAI_WEB
  - DOMAIN-SUFFIX,chat.openai.com,OPENAI_WEB
  - DOMAIN-SUFFIX,chatgpt.com,OPENAI_WEB
  - DOMAIN-SUFFIX,openai.com,OPENAI_WEB
  - MATCH,DIRECT

이렇게 나누면 「API만 느리다」일 때 OPENAI_API만 노드를 바꿔 테스트하기 쉽습니다. 다만 그룹이 늘수록 규칙 순서와 상단의 GEOIP·커스텀 RULE-SET과의 충돌을 더 자주 점검해야 합니다.

⑤ 규칙 우선순위: 위에서 아래로, 앞줄이 이긴다

Clash의 rules는 일반적으로 먼저 매칭된 한 줄이 최종 정책이 됩니다. 그래서 GEOIP,KR,DIRECT나 구독에 포함된 거대 RULE-SET이 api.openai.com보다 위에 있으면, 의도와 다르게 DIRECT나 다른 그룹으로 나가 버릴 수 있습니다. 반대로 지나치게 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다.

재현이 어려울 때는 로그의 매칭된 규칙 이름·행 순서를 스크린샷처럼 남겨 두고, 한 번에 한 줄만 위아래로 옮겨 보는 방식이 안전합니다. 프록시 그룹 계층은 프록시 그룹(proxy-groups) 가이드와 함께 보면 그룹 중첩까지 정리하기 쉽습니다.

⑥ RULE-SET(rule-providers)로 팀 단위 배포하기

여러 PC에 같은 OpenAI 목록을 깔아 두려면 rule-providers로 묶는 방법이 편합니다. 원격 규칙 파일의 출처와 갱신 주기는 사용자가 판단해야 하며, 보안이 중요한 환경에서는 자체 호스트 목록을 Git 등으로 관리하는 편이 낫습니다. RULE-SET은 배포 단위를 바꿀 뿐, DNS 불일치나 TUN 미포착을 자동으로 고쳐 주지는 않는다는 점은 수동 DOMAIN-SUFFIX와 같습니다.

⑦ DNS가 원인일 때: fake-ip, DoH, 조회 경로 엇갈림

증상이 「느리다」가 아니라 간헐적 이름 실패·한 앱만 이상한 IP라면 DNS를 의심합니다. fake-ip 프로필에서는 애플리케이션이 보는 주소와 실제 outbound 경로가 어긋나 보일 수 있고, OS나 브라우저 DoH가 켜진 채 Clash dns 블록도 동작하면 어느 쪽이 먼저 응답했는지에 따라 결과가 달라집니다. API 클라이언트는 프록시 경유 DNS와 직접 조회가 섞이면 원인 추적이 특히 어려워지므로, 한 번에 한 계층만 바꿔 가며 좁히는 것이 좋습니다.

IPv6 우선 해석 뒤 특정 구간에서만 막히는 경우에는 OS·코어 설정의 IPv4/IPv6 일관성도 함께 봅니다. TUN과 DNS를 같이 쓸 때의 절차는 TUN 모드·DNS 심화 글의 순서를 참고하면 후보를 빠르게 줄일 수 있습니다.

⑧ 모드 선택: Rule, Global, Direct와 시스템 프록시·TUN

Rule 모드는 앞서 정한 rules 순서대로 매칭합니다. 문제를 처음 재현할 때는 Global을 잠깐 켜서 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 정책을 먼저 확인해야 합니다.

터미널에서 curl로 api.openai.com을 호출할 때 HTTPS_PROXY를 쓰는지, Clash의 로컬 포트를 직접 지정하는지에 따라 규칙 적용 여부가 달라집니다. IDE·CLI 중심 흐름은 Cursor·GitHub 분류 글과 결이 비슷하지만, 이 글은 호스트 이름을 OpenAI 제품군에 맞춘 것입니다.

⑨ 실측 절차: 브라우저와 API를 각각 검증

1. 프로필 백업: YAML보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
2. Rule 모드: 선택된 프록시 그룹이 의도와 같은지, 상위 GEOIP 등이 OpenAI 호스트보다 먼저 먹지 않는지 확인합니다.
3. 웹 단일 탭: ChatGPT 웹만 연 뒤 Clash 로그에서 매칭된 DOMAIN·정책을 확인하고, 빠진 서픽스를 추가합니다.
4. API 최소 호출: 문서 예시 수준의 작은 요청을 api.openai.com로 보내, 같은 시점에 로그가 기대 그룹으로 찍히는지 봅니다.
5. DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.
6. 모바일: VPN 권한·배터리 제한·앱별 설정이 데스크톱과 달라 동일 YAML이라도 체감이 다를 수 있습니다.

처음 클라이언트를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 훨씬 덜 헷갈립니다. 다른 생성형 AI의 도메인 패턴과 비교하려면 Google Gemini 분류·DeepSeek 웹·API 분류 글을 대조해 보세요.

⑩ 보안·정책·서비스 약관을 함께 기억하기

네트워크 경로를 다루는 방법과 별개로, OpenAI 이용 가능 지역·약관·조직 보안 정책은 사용자가 스스로 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 특정 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다. 기업 환경에서는 IT 부서의 프록시·DLP 정책을 우선합니다.

⑪ 정리: OpenAI는 「API 호스트」와 「웹·플랫폼 호스트」를 한 세트로 보라

2026년에도 ChatGPT와 OpenAI API에 대한 수요는 겹치지만, 패킷 레벨에서는 서로 다른 호스트로 갈라지는 경우가 많습니다. 안정적인 체감은 노드 품질만이 아니라 도메인 규칙이 빠짐없이 매칭되는지, DNS가 같은 경로를 보는지, 규칙 표에서의 순서가 의도와 맞는지에 따라 갈립니다. 반복 시나리오에는 규칙 기반 프록시가 같은 정책을 다시 쓰기 쉬워, 매번 손으로 켜고 끄는 전역 VPN보다 업무·개발 패턴에 맞출 때 유리한 경우가 많습니다.

설치와 버전 안내는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 혼선이 적습니다. 전역 터널보다 관측 가능한 분류에서 Clash가 장기적으로 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, ChatGPT·OpenAI 웹·API용 분류 규칙과 DNS를 맞춰 보세요.