X와 Grok 트래픽은 어떻게 흐르나요?

웹에서 X를 열고 Grok 패널을 쓰면, 화면 하나를 위해 메인 호스트, 정적 CDN, 실시간 API, 이미지·동영상 도메인이 동시에 움직입니다. 이 중 하나라도 규칙상 의도와 다른 출구(DIRECT 등)로 나가거나, DNS 응답이 Clash가 기대하는 경로와 어긋나면 증상은 「전체가 하얗게 비어 있음」「아바타만 계속 로딩」「대화가 한두 턴만 되고 멈춤」처럼 보입니다. 단순 지연과 달리, 이 패턴은 종종 아예 프록시 체인에 안 탄 트래픽에서 시작합니다.

2026년 기준으로는 x.com이 주 진입점으로 쓰이고, 리다이렉트·레거시 링크로 twitter.com이 함께 보이며, 이미지·미디어는 *.twimg.com 계열이 많이 등장합니다. 단축 링크 t.co, 라이브·영상 관련 서브도메인도 따로 잡히는 편입니다. Grok·X 내 AI 기능은 x.ai 같은 호스트로 이어지기도 하는데, 제품 업데이트마다 끝점이 바뀔 수 있으므로 가장 확실한 보강은 문제가 난 순간 연결 로그에 찍힌 실패한 호스트 이름을 그대로 규칙에 반영하는 것입니다.

일반 사용자에게 필요한 것은 「전 세계 모든 서브도메인을 한 번에 외우기」가 아니라, 소셜 미디어 프록시라는 한 업무선—타임라인 보기, 미디어 로딩, 포스팅, Grok 패널—을 Clash Twitter 프록시에 해당하는 하나의 정책 그룹으로 안정적으로 모으고, 규칙 매칭 순서에서 지나치게 넓은 국내 DIRECT에 먼저 잡히지 않게 하는 일입니다.

💡
개발자용 글과의 차이 Cursor·Copilot 쪽은 IDE·CLI·장시간 API 스트림에 맞춘 도메인 묶음이 따로 있습니다. 같은 Clash라도 Cursor·GitHub Copilot 가이드의 목록을 그대로 복사해 X·Grok에 쓰면 빈 구멍이 남을 수 있으니, 사용 시나리오를 분리해 두는 편이 좋습니다.

정책 그룹: 속도보다 안정적인 노드 고정

타임라인과 Grok는 다수의 병렬 HTTPS와 긴 세션에 의존합니다. URL-Test가 너무 자주 노드를 바꾸면, 핸드셰이크가 끝나기 전에 출구가 바뀌어 간헐적 실패로 이어질 수 있습니다. 실무에서는 「소셜·AI 웹」 전용 Selector를 두고, 검증해 둔 노드 한두 개를 수동으로 고른 뒤, 관련 도메인 규칙을 그 그룹으로 보내는 구성이 무난합니다. 자동 선택이 필요하면 간격을 길게 잡거나, 우선 사람이 고정한 뒤에만 자동화를 얹으세요.

공항에서 받은 원격 Rule Provider를 쓰는 경우에도, 클라이언트·병합 방식에 따라 중복 DOMAIN 규칙이 생기거나 순서가 뒤바뀔 수 있습니다. 「미국 노드가 있는가」보다 먼저, 병합 결과에서 어떤 줄이 실제로 먼저 매칭되는지를 확인하는 것이 Grok 접속 불안정을 줄이는 지름길입니다.

재현 예시: 정책 그룹 + X 분류 규칙 초안

아래는 최소 골격입니다. PROXY 자리에는 실제 프로필의 프록시 그룹 이름(예: 구독이 만든 선택 그룹)을 넣고, rules: 블록을 기존 설정과 합칠 때 GEOIP나 지나치게 넓은 DIRECT보다 위에 두는 것이 핵심입니다.

proxy-groups:
  # Dedicated group for X timeline + Grok web; prefer manual select for stability
  - name: X_SOCIAL
    type: select
    proxies:
      - PROXY
      - DIRECT

rules:
  - DOMAIN-SUFFIX,x.com,X_SOCIAL
  - DOMAIN-SUFFIX,twitter.com,X_SOCIAL
  - DOMAIN-SUFFIX,twimg.com,X_SOCIAL
  - DOMAIN-SUFFIX,t.co,X_SOCIAL
  - DOMAIN-SUFFIX,pscp.tv,X_SOCIAL
  - DOMAIN-SUFFIX,video.twimg.com,X_SOCIAL
  - DOMAIN-SUFFIX,x.ai,X_SOCIAL
  - DOMAIN-KEYWORD,grok,X_SOCIAL

운영 포인트는 세 가지입니다. 첫째, X_SOCIAL에 DIRECT를 남겨 두는 이유는 노드 의심 시 빠른 대조용입니다. 평소 타임라인·Grok는 프록시로 고정하고, DIRECT와 프록시를 오가며 긴 연결이 흔들리지 않게 하세요. 둘째, DOMAIN-KEYWORD,grok는 폭이 넓어 다른 사이트를 함께 끌어올 수 있으니, 로그로 호스트를 확인한 뒤 DOMAIN-SUFFIX로 좁히는 것이 안전합니다. 셋째, 구독에 「소셜」 Rule Provider가 이미 있다면 최종 순서가 어디에 로컬 규칙을 끼워 넣느냐에 따라 X 분류 규칙이 무시될 수 있습니다. 병합 정책을 모를 때는 연결 로그의 「실제 매칭 줄」이 기준입니다.

GUI 클라이언트는 YAML 대신 규칙 화면에서 같은 도메인을 같은 정책 그룹에 묶으면 됩니다. DNS·fake-ip·국내외 큰 틀은 문서 센터와 분류 규칙 최적화 튜토리얼을 함께 보고, 소셜 구간만 뜯어 고칠 때 전역 DNS 단락과 충돌하지 않는지 확인하세요.

규칙 순서: 넓은 국내 DIRECT가 앞서면 소셜이 죽습니다

흔한 실수는 앞쪽에 GEOIP나 거대한 국내 직결 세트를 두고, X 관련 도메인은 뒤에만 두거나 주석 처리해 두는 것입니다. 브라우저가 받은 CDN 노드가 그 넓은 규칙에 먼저 걸리면, 리소스가 반쯤만 로드되고 멈춘 것처럼 보입니다. 해결책은 명시적인 DOMAIN-SUFFIX·RULE-SET을 앞당기고, 범용 GEOIP는 뒤에서 받는 구조로 재정렬하는 것입니다.

원격 규칙과 로컬 규칙이 동시에 있을 때 같은 도메인에 DIRECT와 프록시가 중복되면, 사람은 「YAML에 프록시를 썼다」고 기억하지만 실제로는 더 위 줄의 DIRECT가 이깁니다. 분쟁이 나면 YAML 줄 번호가 아니라 로그에 찍힌 최종 정책을 믿고, 그 줄이 어디서 왔는지 역추적하세요.

국내 직결과 해외 프록시의 기본 골격은 스플릿 라우팅 튜토리얼에 정리되어 있으니, GEOIP·사설 대역 세부는 그 글을 참고하고 여기서는 소셜 규칙이 병합 결과에서 어디에 서는지만 반복해 강조합니다.

DNS와 fake-ip: 「메인은 열리는데 그림만 안 나옴」

fake-ip를 쓰는 환경에서 일부 질의만 Clash 밖 DNS로 새면, HTML과 정적 자원의 해석 경로가 갈라져 주소창은 정상인데 썸네일·동영상이 비는 현상이 납니다. 이때 노드를 줄줄이 바꾸기보다, 실패한 이미지 도메인이 DIRECT로 매칭됐는지부터 로그로 확인하는 편이 빠릅니다.

Grok 접속은 긴 연결과 병렬 요청이 겹치기 때문에, DNS가 한 번만 흔들려도 「첫 답변은 되는데 다음이 멈춤」처럼 보일 수 있습니다. 같은 시간대에 정책 그룹 자동 전환이나 DNS 모드 변경, 브라우저 확장이 개입했는지도 함께 보세요.

TUN 모드를 켠 상태라면, OS·브라우저가 Clash를 우회하는 DNS 경로가 없는지 점검해야 합니다. 한 문장으로 정리하면, 규칙은 어떤 출구로 보낼지를 정하고, DNS는 어떤 네트워크 지도를 보여줄지를 정합니다. 둘 중 하나만 맞아도 체감은 크게 어긋납니다.

공식 앱과 브라우저: 경로가 전혀 다를 수 있음

데스크톱·모바일 X 앱은 인증서 핀닝(pinning), 자체 DNS, QUIC 등으로 브라우저와 다른 길을 탈 수 있습니다. 브라우저는 안정적인데 앱만 이상하면, YAML을 대량 수정하기 전에 앱이 시스템 VPN/TUN을 따르는지, QUIC을 강제하는지, 제조사 정책으로 제3자 네트워크 스택이 막히지 않는지부터 보는 것이 비용 대비 효과가 큽니다.

대부분의 사용자에게는 브라우저로 규칙·노드를 먼저 검증하고, 필요할 때만 앱을 손보는 순서가 현실적입니다.

⚠️
준수 사항 거주 지역의 법령과 플랫폼 이용약관을 지켜 주세요. 본문은 접근 권한이 있는 네트워크 환경에서 Clash로 기술적 경로를 맞추고 문제를 줄이는 방법을 설명합니다.

점검 순서: 로그에서 최소 재현까지

「X가 갑자기 안 된다」는 증상은 로그를 보면 대개 소수 도메인과 한두 줄 순서 문제로 수렴합니다. 아래를 고정 절차로 쓰면 재작업을 줄일 수 있습니다.

  1. 연결 로그를 켠 채 타임라인 로딩이나 Grok 전송을 재현하고, 처음 실패한 도메인과 매칭된 정책을 적습니다.
  2. DIRECT나 의도와 다른 그룹으로 나가면 rules 전체에서 해당 도메인을 검색해, 더 위쪽에 짧아지는 규칙이 없는지 봅니다.
  3. X_SOCIAL(또는 동일 역할 그룹)를 단일 안정 노드로 고정하고, 짧은 주기 URL-Test는 잠시 끄고 긴 세션 끊김을 배제합니다.
  4. fake-ip 환경에서는 DNS 단락이 TUN·시스템 프록시 조합과 맞는지 확인하고, 변경 후 Clash를 재시작한 뒤 OS DNS 캐시를 비웁니다.
  5. 시크릿 창이나 광고 차단 확장을 끈 상태에서 재측정해, 스크립트·WebSocket 차단 여부를 분리합니다.

증상: 메인은 열리는데 타임라인이 비어 있음

api·stream·CDN류 서브도메인이 아직 DIRECT인 경우가 많습니다. 로그에서 실패 호스트를 필터링해 노드 교체보다 먼저 규칙을 보강하세요.

증상: Grok 대화가 자주 끊김

정책 그룹 자동 전환이나 UDP 이상이 동반되는지 확인하고, 단일 노드 고정·과도한 자동 측정 해제, 로컬 HTTPS 가로채기 소프트웨어 유무를 점검합니다.

증상: Wi-Fi와 셀룰러에서만 다르게 깨짐

이동통신사 DNS나 IPv6 경로가 Wi-Fi와 다를 수 있습니다. 두 네트워크에서 Clash 로그의 해석·매칭 차이를 비교한 뒤, 셀 전용 규칙이나 DNS 조정 여부를 판단합니다.

정리: X와 Grok 안정화는 도메인·DNS·정책 그룹의 삼각형

UI와 엔드포인트는 바뀌어도, 점검 틀은 비슷합니다. 먼저 로그로 실패 요청이 프록시를 탔는지, 어느 정책 그룹인지를 확인하고, 그다음 규칙 순서와 DNS, 마지막에 노드 교체를 검토하세요. 이렇게 두면 「하루 종일 구독만 갈아엎었는데 DOMAIN 한 줄이 빠진 것」 같은 낭비를 줄일 수 있습니다.

X 분류 규칙을 잘게 나눠 두고 소셜·AI 웹 전용 출구를 안정적으로 유지하면, 체감은 「간헐적 차단의 신비」에서 「로그로 설명 가능한 공학 문제」로 바뀝니다. IDE 플러그인 체인을 다루는 글과 독자층은 다르지만, 경로를 먼저 맞춘 뒤 속도를 논한다는 점은 같습니다.

클라이언트 설치와 구독 가져오기가 아직이라면 다운로드 페이지에서 플랫폼별 패키지를 확인하고, 구독 링크 튜토리얼로 베이스 프로필을 만든 뒤 이 글의 소셜 규칙만 얹으면 됩니다. 환경을 맞춘 다음 → Clash를 무료로 내려받아 분류 규칙과 DNS를 직접 조합해 보세요.