Grok·X가 안 열릴 때: Clash(mihomo)로 xAI와 X(트위터) 도메인을 분기하는 실측 절차 (2026)

1. 왜 Grok·X는 「가끔만」 깨져 보일까

X 클라이언트와 웹은 x.com을 중심으로 하되, 미디어는 pbs.twimg.com·video.twimg.com 등 twimg 계열, 리다이렉트는 t.co로 이어지는 경우가 많습니다. Grok 웹·앱은 grok.com과 x.ai 계열 API·인증 호스트가 섞여 나옵니다. 이 중 일부만 직접 연결이나 다른 프록시 그룹으로 새면, 화면은 반쯤 뜨고 스트리밍·이미지·로그인만 실패하는 패턴이 흔합니다.

또한 최신 브라우저는 HTTP/3(QUIC)을 적극적으로 시도합니다. TUN·방화벽·노드 쪽에서 UDP 443 처리가 TCP와 다르면, 같은 도메인 규칙을 썼는데도 QUIC 핸드셰이크만 불안정해 「새로고침하면 된다」 수준의 증상이 남을 수 있습니다. 그래서 본문은 Clash 분할로 호스트를 고정한 뒤, 필요하면 QUIC을 잠시 끄는 대조 실험을 같은 체크리스트에 넣습니다.

2. ChatGPT·Claude·Gemini 글과의 역할 분담

이 사이트의 ChatGPT 전용 라우팅은 OpenAI 호스트와 세션·IP 안정성에 초점이 있습니다. Claude·Anthropic 글은 지역 메시지와 DNS·fake-ip 조합을 다룹니다. Gemini 글은 Google AI 도메인 묶음과 QUIC을 함께 봅니다. 본문은 그 연장이 아니라, x.com·x.ai·grok.com·twimg 등 xAI·X 축만 분리해 설명합니다. YAML을 복사할 때 호스트 목록을 섞지 않도록 주의하세요.

개발자가 AI API를 붙일 때도 마찬가지입니다. 문서에 나온 엔드포인트와 실제 클라이언트 라이브러리가 치는 호스트가 다를 수 있으므로, 실패한 URL의 호스트 이름을 개발자 도구나 Clash 로그에서 먼저 확정한 뒤 도메인 규칙에 반영하는 루프가 안전합니다.

3. 규칙에 넣기 좋은 xAI·Grok·X 도메인

서비스는 수시로 바뀌므로 아래는 출발점입니다. 네트워크 탭·앱 로그·Clash 로그에 찍힌 호스트를 기준으로 목록을 늘리거나 줄이세요. X·트위터 쪽은 x.com, twitter.com(리다이렉트·구 링크), twimg.com, t.co가 자주 등장합니다. Grok·xAI 쪽은 grok.com, x.ai, 그리고 API 문서에 명시된 서브도메인을 우선합니다.

DOMAIN-KEYWORD,x처럼 지나치게 짧은 키워드는 엉뚱한 사이트까지 잡을 수 있어 비추천입니다. 로그에 반복되는 접미를 DOMAIN-SUFFIX로 쌓는 방식이 운영에 맞습니다.

4. mihomo(Clash Meta) 규칙 스니펫

전용 정책 그룹 이름을 예시로 🔷 XAI-X라고 하면, rules에서 넓은 MATCH·지역 규칙보다 위쪽에 두는 것이 일반적입니다. 그룹·노드 이름은 본인 구독에 맞게 바꿉니다. 규칙 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

rules:
  # xAI / Grok / X — place above broad MATCH / GEOIP
  - DOMAIN-SUFFIX,grok.com,🔷 XAI-X
  - DOMAIN-SUFFIX,x.ai,🔷 XAI-X
  - DOMAIN-SUFFIX,x.com,🔷 XAI-X
  - DOMAIN-SUFFIX,twitter.com,🔷 XAI-X
  - DOMAIN-SUFFIX,twimg.com,🔷 XAI-X
  - DOMAIN-SUFFIX,t.co,🔷 XAI-X
  # Add hosts seen in DevTools / app logs (e.g. api.* subdomains)

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 파일을 덮어쓸 때 커스텀 규칙이 사라지지 않게 하려면 구독 가져오기와 프로필 머지 순서를 확인하세요. 기업망에서는 SNI·차단 목록 때문에 특정 서브도메인만 막히는 경우도 있어, 같은 그룹이라도 노드 지역을 바꿔 대조 실험하는 것이 좋습니다.

5. QUIC·HTTP/3와 UDP 경로

Chromium 계열에서는 chrome://flags 또는 Edge의 edge://flags에서 QUIC 관련 항목을 Disabled로 바꾼 뒤 브라우저를 재시작하고, 동일한 X·Grok 페이지를 다시 열어 봅니다. QUIC을 껐을 때만 안정되면 원인 후보에 UDP·HTTP/3 경로를 올릴 수 있습니다. TUN 모드와 시스템 프록시만 사용할 때 증상이 다르면, 스택 전체에서 UDP가 어떻게 빠져나가는지도 함께 봅니다.

모바일 앱은 브라우저 플래그를 쓸 수 없는 경우가 많습니다. 그때는 Clash 로그에서 해당 앱의 연결이 의도한 규칙으로 나가는지, 캐리어 DNS가 끼어들지 않는지부터 확인합니다. 앱 업데이트 후 호스트가 바뀌면 규칙도 같이 갱신해야 합니다.

6. DNS·fake-ip·DoH 누수

mihomo에서 fake-ip를 쓰면 도메인 규칙과 엔진이 맞물리기 쉬워지지만, 브라우저·OS의 DoH가 강하면 해석이 Clash 밖으로 새어 규칙과 어긋날 수 있습니다. 특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토할 수 있습니다. 아래는 예시이며, 실제 업스트림은 본인 환경에 맞게 교체합니다.

# Optional — example only; use your own resolvers
dns:
  nameserver-policy:
    "+.x.ai":
      - https://dns.google/dns-query
    "+.grok.com":
      - https://dns.google/dns-query

전체 그림은 Clash 개요에서 DNS와 모드 개념을 함께 보는 것이 좋습니다. 서비스 약관·지역 정책은 사용자마다 다르므로, 본문은 네트워크·전송 계층만 다룹니다. 위법을 조장하는 설정이 아니라, 합법적 환경에서 경로를 안정화하는 데 쓰세요.

7. 실측 점검 순서

권장 순서는 다음과 같습니다. 첫째, Clash 로그에서 문제가 된 요청이 의도한 DOMAIN 규칙 줄에 매칭됐는지 확인합니다. 둘째, 🔷 XAI-X에 묶인 노드의 지역·지연이 기대와 맞는지 Proxies 화면에서 봅니다. 셋째, 브라우저에서 QUIC을 끈 상태와 켠 상태를 번갈아 재현합니다. 넷째, VPN·다른 필터·TUN 충돌과 DNS 누수를 점검합니다.

정책 그룹 자동 선택을 쓰는 경우 url-test·fallback 설정이 지나치게 공격적이면 노드가 자주 바뀌어 세션 측면에서 불안정해 보일 수 있습니다. xAI·X처럼 연결이 길게 유지되는 서비스는, 실측상 안정적인 노드를 한동안 고정해 보는 것도 진단에 도움이 됩니다.