왜 «전역 프록시»가 아니라 AI만 골라 보내나요?
생성형 AI 서비스는 2026년 현재에도 접속 경로·계정 정책·API 한도가 자주 바뀌는 영역입니다. 모든 트래픽을 한 노드로 몰아넣으면 국내 사이트까지 불필요하게 우회하고, 반대로 국내 직결만 고정하면 ChatGPT나 OpenAI API 엔드포인트가 막히거나 느려집니다. Clash의 분기 규칙은 «이 도메인은 이 정책 그룹»이라고 한 줄씩만 매칭하면 되므로, AI 업무용 트래픽만 안정적인 아웃바운드로 보내는 데 특히 잘 맞습니다.
핵심은 두 가지입니다. 첫째, 어떤 접미사(suffix)를 프록시로 태울지 목록을 정하는 것. 둘째, 그 목록이 가리키는 정책 그룹 이름이 실제 proxy-groups에 존재하고, 그 안에 쓸 노드·자동 선택 로직이 들어 있는지 확인하는 것입니다. 규칙 줄은 위에서 아래로만 읽히므로, 국내·사설·LAN을 먼저 DIRECT로 보내고 그다음에 OpenAI 묶음을 넣는 식의 순서가 일반적입니다.
DOMAIN-SUFFIX로 묶기 좋은 OpenAI·ChatGPT 관련 도메인
DOMAIN-SUFFIX는 호스트 이름 끝이 일치하면 매칭됩니다. 서브도메인이 많이 바뀌는 서비스일수록 접미사 한 줄로 넓게 잡는 편이 유지 보수에 유리합니다. 아래는 실무에서 자주 쓰는 묶음 예시이며, 클라이언트 로그에 찍힌 실제 호스트를 보며 추가·삭제하는 것이 가장 안전합니다.
- openai.com — 공식 사이트, 일부 리다이렉트·인증 흐름에 포함됩니다.
- chatgpt.com — 브랜드 도메인이 분리된 뒤로 웹 클라이언트·정적 자원 요청에 자주 등장합니다.
- oaistatic.com — UI 자산·스크립트 로딩 등 정적 호스트로 로그에 노출되는 경우가 많습니다.
- oaiusercontent.com — 첨부·업로드 관련 호스트가 잡히는 환경이 있습니다.
- openaiapi-site.azureedge.net 등 CDN·엣지 호스트 — 지역·시점에 따라 달라질 수 있어, 막히면 로그에서 호스트를 확인해
DOMAIN한 줄을 보태는 방식이 낫습니다.
OpenAI API를 쓰는 경우에는 api.openai.com이 대표적이지만, SDK·클라이언트 라이브러리 버전에 따라 다른 서브도메인이 보일 수 있습니다. DOMAIN-SUFFIX,openai.com 한 줄이 상위를 포괄하지만, 과하게 넓게 느껴지면 DOMAIN,api.openai.com처럼 나누어 적는 방법도 있습니다.
DOMAIN-KEYWORD는 왜 신중해야 하나요?
DOMAIN-KEYWORD,openai처럼 짧게 쓰면 편하지만, 전혀 다른 사이트 도메인에 같은 문자열이 포함되면 의도하지 않은 트래픽까지 프록시로 갈 수 있습니다. 가능하면 DOMAIN-SUFFIX로 서비스 경계를 맞추고, 정말 필요할 때만 키워드 규칙을 쓰는 것을 권장합니다.
rules 예시: AI 전용 정책 그룹으로 보내기
아래는 개념을 보여 주는 최소 예시입니다. 앞쪽에 LAN·국내 직결 규칙이 있다고 가정하고, OpenAI 묶음만 AI라는 이름의 정책 그룹으로 보냅니다. 프로젝트마다 그룹 이름·순서는 다르므로, 자신의 프로필에 맞게 이름만 통일하면 됩니다.
rules: - DOMAIN-SUFFIX,openai.com,AI - DOMAIN-SUFFIX,chatgpt.com,AI - DOMAIN-SUFFIX,oaistatic.com,AI - DOMAIN-SUFFIX,oaiusercontent.com,AI # ... 기존 GEOIP·MATCH 등
AI는 proxy-groups에 반드시 정의되어 있어야 합니다. 보통 type: select로 «미국 노드」「저지연 자동」 등을 고르게 하거나, url-test로 응답이 빠른 노드를 고릅니다. 정책 그룹의 역할과 유형별 차이는 YAML 규칙 분기 가이드의 정책 그룹 절을 참고하세요.
순서가 바뀌면 왜 깨지나요?
같은 요청에 두 줄이 동시에 해당한다고 생각해도, Clash는 위쪽 줄 하나만 적용하고 멈춥니다. 그래서 넓은 GEOIP나 MATCH가 OpenAI 줄보다 위에 있으면, 의도와 다른 아웃바운드로 나갈 수 있습니다. 스트리밍·메신저 전용 규칙을 쓰는 프로필이라면, 서비스별 예외 줄을 포괄 규칙보다 위에 두는 습관이 필요합니다.
정책 그룹으로 «AI 전용」 경로 만들기
분기 규칙이 가리키는 것은 결국 «어떤 노드 묶음으로 나갈지»입니다. 일반 해외 프록시용 select와 별도로 AI 그룹을 두면, 웹은 일본 노드·API는 미국 노드처럼 용도별로 아웃바운드를 바꾸기 쉽습니다. 자동 선택을 쓸 때는 테스트 URL이 특정 지역에서만 열리면 오탐이 날 수 있으므로, 가벼운 HTTP 응답을 주는 공용 주소를 쓰는 편이 안전합니다.
proxy-groups: - name: "AI" type: select proxies: - "미국-자동" - "백업-고정" - "DIRECT" - name: "미국-자동" type: url-test proxies: - # 구독에서 받은 노드 이름들
UI에서 그룹 이름을 바꿨다면 rules 쪽 인자도 같은 문자열로 맞춰야 합니다. 오타 한 글자로 코어가 기동 실패하거나 해당 줄만 무시되는 경우가 있으니, 편집 후에는 클라이언트의 프로필 검증·로그 확인을 권장합니다.
흔한 차단·오류와 Clash 쪽에서의 대응
아래 증상은 모두 «프록시가 틀렸다»만이 아니라 DNS·TLS·지역·서비스 정책이 겹칠 때도 비슷하게 보입니다. 순서대로 좁히면 원인 파악이 빨라집니다.
1) 페이지는 뜨는데 채팅만 실패한다
정적 자원은 직결되고 API 호스트만 다른 경로로 가야 하는데, 한쪽만 프록시를 탄 경우입니다. 개발자 도구·코어 로그에서 실패한 요청의 호스트를 확인하고, 해당 접미사를 DOMAIN-SUFFIX 목록에 추가합니다.
2) API는 되는데 브라우저만 안 된다 (또는 그 반대)
시스템 프록시를 쓰지 않는 터미널·Docker는 Clash TUN·환경 변수 HTTPS_PROXY 설정과 각자의 DNS를 따로 갖습니다. «앱마다 규칙이 다르게 적용된다»면 프로세스·인터페이스별 분기가 필요한지, 혹은 해당 앱이 프록시를 우회하는지 확인하세요.
3) TLS 핸드셰이크 오류·인증서 메시지
중간에 HTTPS 검사를 하는 보안 소프트웨어와 충돌하거나, 노드 측에서 SNI 관련 정책이 맞지 않을 수 있습니다. 같은 규칙이라도 노드를 바꾸면 정상화되는 경우는 아웃바운드 품질·지역 이슈에 가깝습니다.
4) 403·«지원되지 않는 지역»류 메시지
이는 순수 라우팅 문제가 아니라 서비스 측 계정·결제·정책일 때가 많습니다. Clash로 경로를 맞춰도 계정 단에서 막히면 동일하게 보일 수 있으니, 공식 상태 페이지·계정 설정과 함께 보아야 합니다.
DNS와 함께 봐야 하는 이유
규칙이 도메인 기준이면, 그 전에 어떤 IP로 해석되느냐가 경로를 바꿉니다. fake-ip 모드를 쓰는 환경에서는 화면에 보이는 IP와 코어 내부 매칭 정보가 달라 보일 수 있어, «규칙을 넣었는데도 DIRECT로 간다»는 혼란이 생기기도 합니다. DNS 섹션의 enhanced-mode, nameserver 체인, 도메인별 분기를 규칙 목록과 같은 날 점검하는 것이 좋습니다.
문제가 반복되면 (1) 해당 호스트에 대해 어떤 DNS가 쓰였는지, (2) 그 결과 IP가 IP-CIDR 규칙에 먼저 걸리지 않는지, (3) Rule Provider 목록이 오래된 캐시만 보고 있지 않은지 순으로 확인해 보세요.
범용 YAML 가이드와의 관계
본 글은 ChatGPT·OpenAI API라는 구체 시나리오에 맞춰 DOMAIN-SUFFIX와 정책 그룹을 어떻게 엮을지 강조했습니다. RULE-SET·GEOIP·Provider 갱신 주기 등 전체 규칙 설계는 Clash YAML 규칙 분기 완전 가이드에서 다루는 편이 체계적입니다. 두 문서를 나란히 두고, 범용 패턴 위에 AI 도메인 묶음만 덧붙이면 프로필이 길어지지 않고도 목적이 분명해집니다.
코어 바이너리 교체·프로토콜 활성화 절차는 미호모 코어 업그레이드 가이드와 연결해 읽으면 설정 흐름이 자연스럽습니다.
마무리
2026년에도 생성형 AI는 웹·API·도구 연동이 동시에 돌아가는 경우가 많습니다. Clash에서는 분기 규칙으로 도메인 묶음을 정하고, 정책 그룹으로 그 묶음이 사용할 아웃바운드를 고르게 만들면, 일상 브라우징과 개발용 API 호출을 한 프로필 안에서 정리할 수 있습니다. 증상이 남으면 규칙만 의심하기보다 DNS·노드·앱별 프록시 설정을 함께 보는 것이 중요합니다.
같은 Clash 계열도 GUI와 머지 방식은 제품마다 다르지만, 최종적으로 코어가 읽는 YAML 한 장을 기준으로 생각하면 디버깅이 빨라집니다. 반복되는 수동 편집보다 검증된 클라이언트에서 프로필을 한 번 맞춰 두는 편이 장기적으로는 더 편한 경우가 많습니다.