Grok 웹이 계속 돌아가나요? Clash로 X(Twitter)·xAI 관련 도메인 분류하기

1. 증상을 세 덩어리로 나누기

사용자 입장에서는 모두 “Grok 이 안 된다”로 느껴지지만, 관찰 지점을 나누면 원인 추적이 빨라집니다. 첫째, X 웹·앱 자체가 느리거나 로그인 루프에 빠지는지. 둘째, X 는 대체로 괜찮은데 Grok 전용 UI(또는 grok 관련 서브 경로)만 응답이 없는지. 셋째, 브라우저는 되는데 터미널·자동화 스크립트가 xAI API 엔드포인트에서만 실패하는지입니다. 이 셋이 갈리면 “노드 하나가 나빠서”보다 특정 접미사가 Clash 규칙에서 빠졌거나 DIRECT 로 새어 나가는 경우를 의심하는 편이 낫습니다.

구독 YAML 이 아직 낯설다면 구독 가져오기 튜토리얼을 먼저 밟고 오면 이후 단계가 훨씬 수월합니다.

2. 권장 점검 순서(실측 기준)

1. Clash 가 켜져 있고 시스템 프록시인지 TUN 인지, 혹은 둘 다인지 메모합니다.
2. 실시간 연결 패널에서 x.com·twitter·twimg·grok·x.ai 문자열을 필터링해 기대한 정책 그룹으로 나가는지, DIRECT 로 새는지 봅니다.
3. fake-ip 사용 여부와 DNS 상위 서버 도달 여부를 확인합니다. 필요하면 특정 접미사에 nameserver-policy 를 둡니다.
4. 미디어 CDN·짧은 링크 리다이렉트까지 도메인 접미사 단위로 규칙에 올리고, 공급자 규칙·GEOIP 보다 앞쪽에 둘지 정리합니다.
5. 규칙이 맞다면 지터가 적은 노드를 고정하고, 짧은 주기 페일오버가 스트리밍·SSE 스타일 응답을 자주 끊지 않는지 봅니다.

범용 오류와 복구 흐름은 Clash 일반 트러블슈팅 가이드와 함께 두면 좋습니다.

3. 시스템 프록시와 TUN: 앱마다 다른 출구

macOS·Windows 의 시스템 프록시는 편하지만, 일부 CLI·샌드박스 앱은 이를 무시합니다. 그 결과 브라우저의 X 는 정상인데, 같은 머신에서 스크립트가 xAI API 를 호출하면 실패하는 식의 환경 불일치가 생깁니다. 반대로 TUN 을 켜면 라우팅 계층에서 잡혀 일관성은 좋아지지만, 다른 VPN 과의 충돌·권한 이슈가 늘 수 있습니다.

TUN 모드 안내에 따라 켠 뒤, 다시 연결 로그에서 X·Grok·xAI 관련 호스트가 모두 Clash 를 통과하는지 확인하세요. 디버깅 기간에는 “한 번에 하나의 출구”만 남기는 것이 원칙입니다.

4. DNS·fake-ip: 스피너처럼 보이는 작은 어긋남

fake-ip 는 체감 속도에 도움이 될 수 있으나, 해석 결과와 실제 연결 목적지가 어긋나면 TLS 재시도가 늘고 사용자에게는 무한 로딩처럼 보입니다. X 는 이미지·비디오·스크립트 호스트가 많아, 한두 접미사만 빠져도 타임라인은 뜨는데 미디어만 깨지거나 Grok 패널 자산이 로드되지 않는 패턴이 나옵니다.

상위 DNS 가 안정적으로 도달하는지 확인한 다음, x.com·twitter.com·twimg.com·x.ai 등 핵심 접미사에 별도 정책을 두어 흔들림을 줄이세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 사용 중인 코어 문서를 함께 보는 것이 안전합니다.

5. X·Grok·xAI 호스트를 의도적으로 나누기

서비스는 단일 도메인이 아니라 메인 웹·미디어 CDN·짧은 링크·API·분석 등으로 퍼집니다. 아래 표는 점검용 체크리스트이며, 실제 이름은 브라우저 개발자 도구 네트워크 탭과 연결 로그로 최신 상태를 확인해야 합니다. 제품 측이 서브도메인을 바꾸면 표의 예시만으로는 부족합니다.

6. 규칙 예시(그룹 이름은 본인 설정으로 교체)

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,x.com,PROXY
  - DOMAIN-SUFFIX,twitter.com,PROXY
  - DOMAIN-SUFFIX,twimg.com,PROXY
  - DOMAIN-SUFFIX,t.co,PROXY
  - DOMAIN-SUFFIX,x.ai,PROXY
  - DOMAIN-KEYWORD,grok,PROXY

API 전용 그룹을 쓰려면 문서에 나온 API 호스트만 PROXY_API 로 빼고, 웹·소셜 트래픽은 PROXY_WEB 에 두면 지연 원인을 나누어 보기 좋습니다. 공급자가 넣은 DIRECT 규칙이 위에서 먼저 매칭되면 의도와 다르게 동작하므로, 규칙 파일 순서와 include 순서를 함께 봐야 합니다. “한 줄 키워드”만으로 끝내기보다, 로그에 찍힌 실제 호스트를 접미사 규칙으로 올리는 쪽이 재발을 줄입니다.

7. 규칙 우선순위: GEOIP·공급자 규칙과의 관계

많은 구독이 하단에 GEOIP 나 광범위한 MATCH 를 둡니다. X·Grok·xAI 용 접미사 규칙을 그보다 위에 두지 않으면, 일부 트래픽은 여전히 직결이나 다른 그룹으로 나가며 “가끔만” 실패하는 현상이 남습니다. 반대로 지나치게 넓은 DOMAIN-KEYWORD 는 다른 서비스까지 끌고 올 수 있으니, 키워드는 최소화하고 로그로 확인된 접미사를 늘리는 편이 안전합니다.

팀 단위로 운영한다면, 한 번 맞춘 규칙 스니펫을 내부 위키에 “증거 URL·캡처한 호스트 목록”과 함께 남겨 두세요. 이후 제품 측 변경이 있어도 비교 기준이 생깁니다.

8. 정책 그룹과 노드: 스트리밍형 응답을 끊지 않기

순간 속도 벤치마크가 높아도 짧은 구간에서 패킷 손실·지터가 크면 HTTP/2 스트림이 자주 재협상되며, 사용자에게는 긴 스피너나 중간 끊김으로 보입니다. AI 웹 UI 는 때때로 긴 응답을 스트리밍에 가깝게 받기 때문에, 지나치게 공격적인 자동 페일오버가 세션을 자주 끊지 않는지 확인하세요. 전송 계층 특성은 프로토콜 비교 글을 참고해 보조 근거를 얻을 수 있습니다.

9. 연결 로그로 교차 검증하기

추측으로 노드를 바꾸기 전에, 어떤 호스트가 어떤 정책에 걸렸는지를 한 번에 적어 두세요. GUI 클라이언트의 실시간 연결 목록에서 도메인 문자열을 복사해 팀 위키에 붙여 두면, 이후 동일 증상이 재현될 때 비교 기준이 됩니다. DIRECT 인데 지역 제한이 있는 경로로 나가면 “X 는 되는데 Grok 만 이상하다” 같은 부분 실패도 설명됩니다.

10. GUI 워크플로: Clash Verge Rev

필터로 x.com·twimg·x.ai 등을 걸면 잘못된 정책 적중을 빠르게 찾을 수 있습니다. 설치와 구독 흐름은 초보자 가이드를 따르세요.

11. 다른 생성형 AI 글과의 관계

같은 “생성형 AI 프록시”라도 호스트 집합이 완전히 다릅니다. ChatGPT·OpenAI 분류 가이드는 openai.com·chatgpt.com 축이고, Claude·Anthropic 분류는 anthropic.com·claude.ai 축입니다. Perplexity 쪽 CDN·검색 호스트는 Perplexity 분류 글을 참고하세요. 이 글은 X 생태·Grok·xAI 축으로, 위 문서들과 나란히 두면 팀 내 네트워크 체크리스트로 쓰기 좋습니다.

12. 추가 함정: 확장·이중 VPN·기업 프록시

브라우저 확장이 자체 프록시를 켜 두면 OS 설정과 겹쳐 혼란이 커집니다. 점검 시에는 잠시 끄세요. Clash 외 다른 상시 VPN 과 동시에 켜면 루프나 이중 터널처럼 보이는 증상이 납니다. 기업망에서 SSL 검사를 하는 경우, 클라이언트 인증서 경고나 핸드셰이크 실패가 별도로 나올 수 있어, 그때는 프록시 분류 이전에 보안 정책을 확인해야 합니다.

13. 정리: 로그 한 줄이 곧 증거입니다

Grok 프록시 문제는 단일 스위치가 아니라 모드·DNS·규칙 순서·노드 품질이 겹친 결과인 경우가 많습니다. X 접속과 xAI API 를 도메인 단위로 올리고, Clash 분류 로그에 찍힌 정책 이름을 기록하면 불필요한 노드 순환을 줄일 수 있습니다. 스피너만 도는 현상을 줄이려면 “더 빠른 노드”보다 “같은 세션을 안정적으로 유지하는 출구”와 “빠지지 않은 접미사 목록”을 우선하세요.

설정 파일을 매번 손으로 다듬기보다 Mihomo 를 내장한 공식 클라이언트에서 로그와 업데이트를 한곳에 모으는 편이 실무에 편할 때도 많습니다. → Clash 를 무료로 내려받고 차이를 직접 확인해 보세요