1 Grok·xAI·X를 한데 묶어 규칙을 두는 이유
2026년에도 «단일 AI 제품»만 놓고 보면 ChatGPT·Claude·Gemini·DeepSeek·Perplexity처럼 브랜드별로 도메인 집합이 뚜렷이 갈라진 경우가 많습니다. 그런데 Grok는 xAI가 제공하는 모델·API이면서, 실사용에서는 X(구 Twitter) 앱·웹의 계정·구독·타임라인과 같은 제품 경험 안에 자주 묶입니다. 즉 네트워크 관점에서는 x.ai 계열과 x.com·twitter.com·이미지·숏링크 등 X 플랫폼 호스트가 동시에 등장하고, 한쪽만 프록시에 넣으면 «웹 콘솔은 되는데 앱에서 Grok 패널만 비는», «API는 되는데 X 로그인 세션이 다른 출구로 나간다» 같은 증상이 갈라집니다.
Clash에서는 DOMAIN-SUFFIX와 Rule Provider로 이 두 축을 명시적으로 적어 두고, 지연·안정성에 맞춘 프록시 그룹 이름을 규칙에서 참조합니다. 목적은 속도 경쟁이 아니라 연결 로그에 찍힌 SNI마다 기대한 정책이 걸리게 해서, 브라우저·X 모바일 앱·터미널의 api.x.ai 호출이 같은 노드 정책을 쓰게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 Mihomo를 지원하는 GUI를 고른 뒤, 아래 YAML 조각을 기존 프로파일에 합치면 됩니다.
2 xAI 스택: x.ai·api.x.ai·콘솔·문서
공식 개발자 문서와 콘솔은 보통 x.ai 루트 아래 서브도메인으로 나뉘고, REST API 베이스는 https://api.x.ai 형태를 씁니다. DOMAIN-SUFFIX,x.ai 한 줄이면 api.x.ai·docs.x.ai·console.x.ai 등 같은 접미사 트리에 속하는 호스트를 한꺼번에 규칙에 태울 수 있습니다. 다만 마케팅용으로 grok.com 등 별도 루트가 로그에 보이면 그때그때 DOMAIN-SUFFIX를 한 줄 더하는 식으로 보강하는 것이 안전합니다. 서비스가 바뀌면 호스트도 늘어나므로 «한 번 적고 끝»보다 연결 로그 기반 유지보수를 전제로 두세요.
SDK·curl·CI 스크립트는 시스템 프록시를 무시하는 경우가 많아, 브라우저만 정상이고 터미널만 타임아웃하는 패턴이 자주 납니다. HTTPS_PROXY를 Clash 리스닝 주소에 맞추거나 TUN으로 통일하면 재현성이 좋아집니다. OpenAI 호환 베이스 URL만 바꾸는 마이그레이션을 할 때도, 출구 노드가 문서에 쓴 예제와 다르면 401·TLS 오류를 네트워크 탓으로 착각하기 쉽습니다.
3 X 플랫폼: x.com·레거시 twitter.com·미디어·숏링크
X는 도메인 이전 이후에도 twitter.com 리다이렉트·모바일 클라이언트 호환·API 호스트명 등으로 여러 루트 도메인이 동시에 살아 있습니다. 사용자가 보는 웹은 x.com이 중심이어도, 이미지·비디오·추적·숏 URL은 twimg.com·t.co 등으로 갈라지는 경우가 많습니다. «소셜 한 줄» 규칙만 켜 두면 일부 호스트가 직접 연결로 빠져 피드는 보이는데 미디어만 안 열리는 식의 불균형이 납니다. Grok UI가 X 앱 안에 붙어 있으면, xAI 쪽만 프록시에 넣고 X 본체를 빼면 오히려 세션이 엇갈릴 수 있으니, 실제 사용 시나리오에 맞춰 같은 프록시 그룹에 넣을지, 지연 때문에 둘로 쪼갤지 결정하세요.
iOS·Android X 앱은 시스템 프록시를 따르지 않는 경우가 많아 Wi-Fi에서 브라우저만 되고 앱만 실패하는 패턴이 흔합니다. 이때는 TUN으로 기기 전체를 규칙 엔진에 넣는 편이 단순합니다. Android에서는 FlClash 설정 글, iOS에서는 Stash 구독 가져오기 맥락을 참고해 VPN 슬롯·배터리 최적화 예외를 함께 점검하세요.
4 DOMAIN-SUFFIX 묶음·규칙 순서·DNS
실무에서는 최소한 DOMAIN-SUFFIX,x.ai로 xAI 축을 잡고, X는 DOMAIN-SUFFIX,x.com·DOMAIN-SUFFIX,twitter.com·DOMAIN-SUFFIX,twimg.com·DOMAIN-SUFFIX,t.co처럼 자주 보이는 루트를 나란히 둡니다. 연결 로그에 video.twimg.com·분석 호스트 등이 따로 보이면 한 줄씩 추가하거나, 신뢰할 수 있는 원격 Rule Provider에 합치고 interval로 갱신하세요. DOMAIN-SUFFIX,x.ai가 있으면 별도로 api.x.ai를 한 번 더 쓸 필요는 대개 없습니다(서브도메인이 동일 접미사에 포함되기 때문입니다).
규칙 순서에서 넓은 MATCH나 «해외 전체»가 위에 있으면 Grok·X 전용 줄이 도달하기 전에 흡수되거나, 반대로 직접 연결이 먼저면 TLS에서 끊깁니다. 범용 구독 규칙보다 앞쪽에 두고, Connections 로그에서 x.ai·x.com 등으로 필터해 기대한 PROXY_GROK_X 같은 그룹이 찍히는지 확인하세요.
DNS·FakeIP 설계는 DNS 유출 방지 가이드와 맞추는 것이 안전합니다. SNI와 정책이 어긋나면 «가끔만 인증서 오류»처럼 보이기도 합니다.
5 Rule Provider와 rules: 예시
아래는 개념 예시입니다. proxy-groups 이름·노드 목록은 본인 프로파일과 맞추고, rule-providers의 url은 실제로 신뢰하는 목록으로 바꾸세요. 원격 목록이 없으면 RULE-SET 줄을 빼고 DOMAIN-SUFFIX만 나열해도 됩니다. xAI와 X를 한 그룹에 둘지, 지연 때문에 두 그룹으로 나눌지는 팀 정책에 따라 고르세요.
# Example only — merge with your full profile
proxy-groups:
- name: PROXY_GROK_X
type: select
proxies:
- AUTO-BEST
- DIRECT
rule-providers:
grok_x:
type: http
behavior: classical
url: "https://example.com/rules/grok-x.txt"
path: ./ruleset/grok-x.yaml
interval: 86400
rules:
- RULE-SET,grok_x,PROXY_GROK_X
- DOMAIN-SUFFIX,x.ai,PROXY_GROK_X
- DOMAIN-SUFFIX,x.com,PROXY_GROK_X
- DOMAIN-SUFFIX,twitter.com,PROXY_GROK_X
- DOMAIN-SUFFIX,twimg.com,PROXY_GROK_X
- DOMAIN-SUFFIX,t.co,PROXY_GROK_XDOMAIN-KEYWORD,grok나 twitter는 무관한 사이트까지 건드리기 쉽습니다. 접미사·신뢰할 수 있는 RULE-SET을 우선하고 KEYWORD는 임시 진단용으로만 쓰세요.
6 모바일 앱·TUN·분할 터널
앱이 시스템 VPN/TUN 슬롯을 쓰지 않으면 DNS조차 기대한 resolver로 가지 않을 수 있습니다. «브라우저에서는 Grok 문서가 열리는데 X 앱만 불안정하다»면 HTTP 프록시만으로는 부족한 경우가 많고, Clash 측 TUN 또는 모바일 클라이언트의 동등한 전역 라우팅을 켜야 합니다. 분할 터널(앱별 예외)을 쓰는 경우 X·xAI 관련 앱이 예외 목록에서 빠지지 않았는지 확인하세요. 예외에 넣으면 다시 직접 연결로 나가 규칙이 적용되지 않습니다.
Cursor·Clash 글은 IDE·확장 마켓 호스트에 초점이 있고, 본문은 소셜·xAI API가 한데 묶인 환경에서의 출구 일치에 초점을 둡니다. 둘 다 쓰면 규칙을 단순히 합치기보다 로그로 각각 검증하는 편이 안전합니다.
7 GEOSITE 한 덩어리에만 기대지 않기
구독에 들어 있는 GEOSITE·거대 «비중국» 묶음은 편하지만 해상도가 거칠고 갱신도 커뮤니티 속도에 묶입니다. AI·소셜 트래픽만 낮은 지연 노드로 보내고 싶은데 무관한 사이트까지 같은 출구를 타게 되거나, 새 CDN 호스트가 목록에 없으면 직접 연결로 새었다가 끊기는 일이 생깁니다. 범용 규칙 위에 Grok·xAI·X 전용 RULE-SET 또는 DOMAIN-SUFFIX 줄을 덧씌우는 편이 팀에서도 설명하기 쉽습니다.
8 API·콘솔·문서·과금 화면
공식 SDK나 REST 클라이언트가 api.x.ai를 부르면 네트워크 레이어에서는 브라우저·앱과 같은 프록시 그룹을 타는 것이 디버깅에 유리합니다. 키 발급·사용량·과금을 위해 console.x.ai 등 웹 콘솔에 들어갈 때도 동일 정책이 걸리게 두면 «웹은 되는데 스크립트만 실패» 같은 불일치를 줄일 수 있습니다. 문서 사이트는 읽기 전용이어도 차단되면 삽입된 예제·리다이렉트가 깨질 수 있으니 x.ai 접미사 한 덩어리로 묶는 편이 단순합니다.
출처 불명의 공용 프록시에 API 키를 태우지 마세요. 회사망에서는 보안 정책에 따라 프록시 사용 자체가 제한될 수 있습니다.
9 API 키·쿼터·준수
연결이 되어도 401·403·429·쿼터 초과·결제 오류는 계정·프로젝트 설정 문제일 수 있습니다. 키는 저장소에 올리지 말고 비밀 저장소·최소 권한으로 관리하세요. 본문은 클라이언트 측 경로 가용성만 다루며 지역 법규·고용 계약·서비스 약관 해석을 대신하지 않습니다.
10 DNS·로그·자주 보는 오류
«해석은 되는데 연결이 안 된다»면 DNS 단계와 TCP·TLS 단계를 나누어 보세요. FakeIP·DoH·fallback이 꼬이면 규칙은 맞는데 세션이 다른 출구로 나가기도 합니다. 노드를 바꿀 때마다 같은 호스트가 들쭉날쭉하면 선로 품질을 의심하고, 노드를 고정한 채 로그의 호스트 목록을 한 번에 모아 보는 편이 빠릅니다.
스트리밍 응답이 중간에 끊기면 HTTP/2와 불안정한 회선 조합도 흔한 원인입니다. 브라우저에서 xAI 콘솔까지 확인 → 최소 스크립트로 api.x.ai 헬스 체크 → X 앱에서 동일 계정으로 재현 순서를 권장합니다.
- 브라우저만 되고 X 앱만 실패: TUN 미적용·분할 터널 예외·배터리 최적화를 의심합니다.
- X는 되는데 API만 401/403: 규칙보다 키·계정·쿼터를 먼저 확인합니다.
- 미디어만 안 열린다:
twimg.com등이 규칙에 포함됐는지, 더 넓은 규칙에 먼저 잡히지 않았는지 봅니다. - 간헐적 TLS 오류: DNS·SNI·중간 프록시 충돌 가능성을 점검합니다.
11 자주 묻는 질문
- ChatGPT 규칙만 있으면 되나요? OpenAI 도메인과 xAI·X 도메인은 다릅니다. 본문의
x.ai·X 플랫폼 묶음을 추가하세요. - xAI만 프록시에 넣고 X는 직접 연결로 두면? 가능은 하지만 Grok·계정 UX가 한데 묶인 시나리오에서는 세션이 엇갈릴 수 있습니다. 로그로 검증하세요.
- Perplexity·Gemini 규칙과 충돌? 순서와 프록시 그룹만 분리하면 병행 가능합니다. 대상 도메인이 다릅니다.
- Windows 스토어 앱에서만 이상하다: Windows UWP·Loopback 글을 참고해 예외를 점검하세요.
12 정리
2026년에도 Grok·xAI API와 X 플랫폼을 같이 쓰는 경우, «전역 스위치 하나»나 거대 GEOSITE 한 덩어리보다 호스트 묶음을 유지보수 가능하게 두는 편이 낫습니다. Clash에서 DOMAIN-SUFFIX·Rule Provider로 x.ai 축과 x.com·twitter.com·twimg.com·t.co 등 X 축을 전용 프록시 그룹에 묶고, 브라우저·앱·터미널을 TUN 또는 환경 변수로 맞추면 로그 기반 디버깅이 쉬워집니다. 규칙 가독성과 클라이언트 선택 폭에서 다른 도구들보다 실무에 잘 맞는 경우가 많습니다.
설치 패키지는 공식 다운로드 페이지를 우선하세요. 소스·이슈는 GitHub 등을 참고하되, 배포물은 사이트 경로를 쓰는 편이 버전 관리에 유리합니다.
