증상을 이렇게 나눠 보세요
같은 브라우저에서 검색·뉴스·동영상은 빠른데 Grok 웹 UI만 스피너가 돌거나 응답이 늦게 붙는 패턴은 흔합니다. 때로는 첫 화면은 뜨다가 대화 입력 후에만 멈추기도 하고, 특정 리전 노드에서는 캡차·로그인 플로만 반복되는 경우도 있습니다. 이때 「전역 프록시를 켰으니 다 됐다」고 가정하면, 실제 트래픽이 의도한 출구를 타지 않고 있거나, DNS만 엇나가서 TLS가 꼬이는 케이스를 놓치기 쉽습니다.
본문에서는 Cursor·GitHub 같은 개발자 도구 타임아웃과는 다른 축인, 브라우저 기반 AI 대화 제품의 전형적인 호스트명과 SNI를 기준으로 Clash(Mihomo) 쪽 분류 규칙을 짜는 방법을 다룹니다. 도메인 구성은 서비스 업데이트로 바뀔 수 있으므로, 아래 예시는 점검용 출발점으로만 두고 클라이언트 로그·개발자 도구의 네트워크 탭으로 최신 호스트를 보완하는 습관이 필요합니다.
왜 xAI·Grok만 별도 정책 그룹을 두는가
많은 프로필이 GEOIP,CN,DIRECT나 광고 차단·국내 CDN 직결 목록을 상단에 두는데, 여기에 넓은 DOMAIN-SUFFIX나 오래된 로컬 리스트가 끼어 있으면 해외 AI 트래픽이 의도치 않게 직결로 떨어질 수 있습니다. 직결이 항상 「빠름」을 의미하지 않습니다. 일부 회선에서는 해외 SNI가 필터링되거나, 직결 경로가 오히려 RTT·패킷 손실이 커서 무한 로딩처럼 보이기도 합니다.
따라서 Grok·xAI 계열을 AI-XAI 같은 전용 proxy-group으로 묶고, 그 그룹에는 지연·안정성이 검증된 노드만 넣는 방식이 운영하기 쉽습니다. 나머지 웹은 기존 「자동 선택」 그룹을 쓰더라도, AI 한 탭만 수동으로 다른 노드를 고를 수 있어 A/B 비교가 빨라집니다. 규칙 세트를 원격으로 구독한다면 Rule Providers·rule-set 구성을 함께 읽어 두면 유지보수 부담이 줄어듭니다.
대표 도메인·SNI를 잡는 실무 순서
웹 제품은 정적 자산·API·인증이 서로 다른 호스트로 쪼개지는 경우가 많습니다. 브라우저 개발자 도구에서 실패한 요청의 Host를 확인하고, Clash 로그에서 매칭된 규칙 이름과 실제 프록시 체인을 대조하세요. 출발점으로 자주 등장하는 패턴에는 grok.com, x.ai, accounts.x.ai, api.x.ai 등이 있습니다(시점에 따라 추가 서브도메인이 생길 수 있음).
YAML에 직접 쓸 때는 DOMAIN-SUFFIX로 상위 도메인을 덮는 방식이 단순합니다. 다만 DOMAIN-KEYWORD는 범위가 넓어 오탐이 나기 쉬우니, 운영 프로필에서는 가능한 한 피하거나 별도 테스트 프로필에서만 쓰는 것이 안전합니다. Mihomo 계열에서는 원격 RULE-SET에 행동(classical vs domain)을 맞추는 것도 잊지 마세요.
# Example — verify hostnames in your browser/network log before use
proxy-groups:
- name: AI-XAI
type: select
proxies:
- 🇯🇵 Low-latency
- ♻️ Auto
- DIRECT
rules:
- DOMAIN-SUFFIX,grok.com,AI-XAI
- DOMAIN-SUFFIX,x.ai,AI-XAI
- DOMAIN-SUFFIX,accounts.x.ai,AI-XAI
- DOMAIN-SUFFIX,api.x.ai,AI-XAI위 블록은 예시일 뿐이며, 실제 규칙 순서는 프로필 전체와 충돌하지 않게 조정해야 합니다. 특히 더 위쪽에 있는 DIRECT·REJECT 규칙이 먼저 맞으면 아래쪽의 AI 그룹은 영원히 호출되지 않습니다.
DNS·fake-ip가 Grok 접속을 망치는 경우
Clash의 DNS 모드가 fake-ip일 때, 브라우저·시스템 resolver와 코어 내부 resolver가 서로 다른 답을 들고 있으면 증상이 기묘해집니다. 한쪽은 프록시를 타고 다른 쪽은 직결이라, 연결은 되는데 앱 레벨에서만 타임아웃처럼 보이기도 합니다. redir-host와 fake-ip를 바꿔 가며 재현되는지 확인해 보세요.
또한 DoH/DoT 업스트림이 지역별로 다른 IP를 돌려주면, SNI 기반 규칙은 맞는데 실제 패킷 목적지가 기대와 달라지는 경우가 있습니다. 이때는 DNS 쿼리가 어떤 nameserver 그룹을 타는지, fallback이 너무 빨리 발동하는지를 점검합니다. TUN 모드와 병행한다면 TUN 모드 가이드의 DNS·스택 설명과 함께 보는 것이 이해가 빠릅니다.
직결(DIRECT) 오매칭·규칙 순서 함정
사용자가 수집한 「중국 사이트 직결」 리스트에 예전 데이터가 남아 있거나, CDN IP 대역이 겹치면 해외 AI 호스트가 DIRECT로 분류될 수 있습니다. 반대로, 광범위한 FINAL,PROXY만으로는 부족하고, 특정 ASN·GEOIP 규칙이 먼저 걸려 원하지 않는 출구로 나가는 경우도 있습니다.
해결책은 두 가지입니다. 첫째, Clash 대시보드나 로그에서 해당 세션의 rule hit를 확인해 어떤 줄에 걸렸는지 이름을 남깁니다. 둘째, AI 전용 규칙을 충돌하는 DIRECT 규칙보다 위로 올리되, 너무 광범위한 DOMAIN 규칙으로 다른 서비스를 망가뜨리지 않도록 범위를 좁힙니다. rule-provider를 여러 개 쓰면 파일 합쳐진 뒤의 실제 순서가 직관과 다를 수 있으니, 최종 렌더 결과를 클라이언트가 보여 주는 규칙 목록으로 한 번 검증하세요.
UDP·QUIC·WebSocket에서 생기는 오해
크롬 계열은 HTTP/3(QUIC, UDP)을 선호하는 경우가 많습니다. 프록시 노드나 중간 방화벽이 UDP를 막거나 성능이 나쁘면, TCP로 폴백되기 전까지 화면이 비어 있는 것처럼 느껴질 수 있습니다. 클라이언트에서 QUIC 관련 실험을 끄거나, 브라우저에서 HTTP/3를 잠시 비활성화해 증상이 사라지는지 비교해 보면 단서가 됩니다.
WebSocket·SSE 스트림은 장시간 연결이라 유휴 타임아웃에 걸리기 쉽습니다. 이때는 노드 프로토콜(TCP 기반인지, multiplex 지원인지)과 클라이언트의 keep-alive 계열 옵션을 함께 봐야 합니다. 「AI 도구 프록시」는 단발 HTTP GET 한 방이 아니라 긴 세션이 기본이라는 점을 염두에 두세요.
재현 가능한 자가 점검 체크리스트
아래 순서는 현장에서 메모하기 좋게 짧게 유지했습니다. 각 단계에서 「전후 로그 한 줄」만 남겨도 나중에 동료에게 넘기기 쉽습니다.
- 브라우저에서 실패한 요청의 호스트명과 상태 코드를 기록한다.
- Clash에서 동일 시각의 연결이 어느 policy와 rule에 매칭됐는지 확인한다.
- 같은 노드로 다른 해외 HTTPS 사이트를 열어 회선 자체 이슈인지 가른다.
- DNS 모드·nameserver·fallback을 바꿔 재현 여부를 본다.
- AI-XAI 그룹에서 노드를 수동 전환해 지연·손실 차이를 비교한다.
- TUN/시스템 프록시/브라우저 확장이 동시에 개입하는지 확인한다.
이 과정을 거치면 「Grok 접속이 안 된다」는 막연한 보고를 xAI 관련 호스트가 DIRECT에 걸림, UDP 경로 불량, DNS 이중 해석 같은 구체 가설로 바꿀 수 있습니다.
정리
Grok 같은 xAI 웹 제품이 Clash 환경에서만 유독 불안정하다면, 원인은 종종 노드 품질 하나가 아니라 규칙·DNS·전송 프로토콜의 조합에 있습니다. AI 전용 정책 그룹과 좁은 DOMAIN-SUFFIX 규칙으로 출구를 고정하고, rule hit 로그로 직결 오매칭을 걸러 내면 같은 증상을 훨씬 빠르게 닫을 수 있습니다.
장기적으로는 원격 rule-set으로 도메인 목록을 갱신하고, 로컬 YAML에는 충돌이 적은 최소 규칙만 남기는 편이 안전합니다. 더 넓은 라우팅 개념은 문서 허브의 고급 설정 파트와 맞춰 읽으면 흐름이 연결됩니다. 다른 AI 서비스를 쓸 때도 같은 골격을 재사용할 수 있어, Clash 분류 규칙을 한 번 정리해 두면 이후 확장 비용이 줄어듭니다.
동일한 Mihomo 코어를 쓰는 클라이언트라도 UI에서 보이는 로그 형식이 조금씩 다를 수 있으나, 어떤 규칙에 맞았는지와 어느 그룹으로 나갔는지만 일관되게 확인할 수 있으면 충분합니다. 브라우저 한 탭의 체감 속도는 전역 지표보다 민감하니, 작은 프로필 분리(일상용 vs AI 실험용)도 좋은 타협입니다.