어떤 증상에 이 글이 해당할까

Meta Threads(웹 threads.net)는 X(트위터)와 비교되는 소셜 플랫폼으로, 웹 클라이언트는 화면 뼈대와 데이터·미디어를 서로 다른 호스트에서 불러옵니다. Clash나 mihomo에서 프록시는 켜 두었는데도 아래 증상이면 DOMAIN-SUFFIX,threads.net 한 줄만으로는 부족했을 가능성이 큽니다.

  • 주소 표시줄은 threads.net인데 본문·피드가 비어 있거나, 상단 로고만 있고 무한 스피너만 돈다.
  • 텍스트 일부는 나오는데 프로필 이미지·첨부 미디어·스레드 본문 블록만 계속 로딩된다.
  • 브라우저 개발자 도구 네트워크 탭에서 JS 번들·API 요청만 빨간색(실패)으로 보인다.
  • 같은 Wi-Fi에서 다른 사이트는 정상인데 Threads 웹만 반복적으로 깨진다.

이 패턴은 “노드 하나가 불안정해서”보다 rules 배열에서 첫 매칭된 줄이 호스트마다 달라져 출구가 갈라질 때 더 흔합니다. 단축 도메인·CDN을 한 묶음으로 정리한 Reddit redd.it·CDN 글이나 Telegram t.me·DC 분기 글과 같은 유형으로 이해하면 유지보수가 쉬워집니다.

왜 threads.net만 프록시하면 화면이 비는가

Threads 웹의 표면 도메인은 threads.net이지만, 실제 트래픽은 (1) 앱 셸·라우팅용 threads.net 자체, (2) Meta 계열이 공유하는 Instagram CDN(cdninstagram.com 등), (3) graph·API에 가까운 instagram.com 서브도메인, (4) 필요 시 Facebook CDN(fbcdn.net 등)으로 나뉩니다. HTML 문서만 프록시로 받고 정적 자산이 GEOIP나 넓은 MATCH 아래에서 DIRECT로 떨어지면, 브라우저는 빈 캔버스만 그린 채 JS를 기다리다 흰 화면·스피너로 보일 수 있습니다.

또한 브라우저는 OS 프록시를 따르지만, DNS prefetch나 확장 프로그램, 다른 VPN이 끼어 있으면 Clash가 보기에 맞는 규칙과 실제 SYN이 나가는 경로가 어긋날 수 있습니다. 영상·CDN이 따로 끊기는 일반 원리는 스트리밍 분기 글에서도 같은 맥락으로 다룹니다.

팁

문제가 난 순간 Connections 창을 켜 두고 탭을 새로고침하세요. 실패한 줄의 도메인·SNI를 적어 두면, DOMAIN-KEYWORD,meta처럼 과하게 넓은 규칙 없이도 누락 호스트를 보완할 수 있습니다.

호스트를 역할별로 묶기 (출발점)

엔드포인트는 배포·A/B 테스트에 따라 바뀔 수 있으므로 아래는 교육용 출발점이며, 최종 기준은 항상 본인 로그입니다.

  • 웹 메인: threads.net, www.threads.net — 문서·일부 API 진입.
  • Instagram CDN: cdninstagram.com 및 지역별 호스트 — 이미지·정적 자산에 자주 등장합니다.
  • Instagram API·인증 축: instagram.com의 서브도메인(예: graph.instagram.com 등) — 로그에 찍힌 이름을 우선합니다.
  • Facebook CDN: fbcdn.net 등 — Threads와 인스타그램 웹에서 공통으로 보일 수 있으나 범위가 넓어 로그 확인 후 추가하는 편이 안전합니다.

처음에는 threads.net와 cdninstagram.com부터 같은 전략 그룹에 넣고, 남는 실패 호스트만 DOMAIN-SUFFIX로 덧붙이는 방식이 실수가 적습니다. DNS가 fake-ip 모드라면 이름 해석과 규칙 매칭이 어긋나지 않는지 YAML·DNS 가이드의 fake-ip-filter·nameserver 설정과 함께 대조하세요.

전략 그룹: PROXY_THREADS

운영상 이름은 PROXY_THREADS처럼 고정해 두면 규칙 줄과 주석을 맞추기 쉽습니다. 타입은 대개 select가 무난하고, 자동 url-test가 너무 자주 출구를 바꾸면 세션·쿠키가 끊기는 체감이 날 수 있으니 재현 테스트 때는 한동안 노드를 수동 고정해 비교하는 것이 좋습니다.

instagram.com 전체 접미사를 한꺼번에 넣으면 같은 기기에서 인스타그램 앱·웹을 의도와 다르게 모두 프록시 탈 수 있습니다. Threads 웹만 문제인지, 인스타그램까지 한 묶음으로 가져가도 되는지 정책을 먼저 정한 뒤 범위를 정하세요. 처음에는 threads.net + cdninstagram.com만 묶고, 로그에 graph.instagram.com 등이 반복될 때 DOMAIN 또는 DOMAIN-SUFFIX를 추가하는 순서를 추천합니다.

규칙 예시 (개념 스케치)

rules는 위에서 아래로 평가되며 첫 매칭이 최종입니다. Threads 전용 줄은 넓은 GEOIP,CN·MATCH보다 위에 두되, 사내망·은행·결제 예외는 그보다 더 위에 둡니다. 프록시 이름은 본인 프로필에 맞게 바꿉니다.

# Conceptual excerpt — adapt proxy group names and your upstream nodes
proxy-groups:
  - name: PROXY_THREADS
    type: select
    proxies:
      - NODE_STABLE_A
      - NODE_STABLE_B
      - PROXY_DEFAULT

rules:
  - DOMAIN-SUFFIX,threads.net,PROXY_THREADS
  - DOMAIN-SUFFIX,cdninstagram.com,PROXY_THREADS
  - DOMAIN-SUFFIX,instagram.com,PROXY_THREADS
  - DOMAIN-SUFFIX,fbcdn.net,PROXY_THREADS
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

instagram.com·fbcdn.net 줄은 영향 범위가 넓습니다. 안정화 후에는 로그에서 확인된 서브도메인만 남기거나, 구독 RULE-SET 안의 Meta 관련 세트와 중복·순서를 함께 점검하세요. DOMAIN-KEYWORD,threads는 다른 서비스와 겹칠 여지가 있어 임시 진단용에 가깝습니다.

DNS·Fake-IP가 의심될 때

증상이 “문서는 열리는데 특정 API·정적 호스트만 타임아웃”이면 Fake-IP와 앱·브라우저 내부 DNS가 엇갈리는 경우를 의심할 수 있습니다. Threads 웹이 시스템 DNS를 직접 쓰는 경로가 섞이면 Clash 로그상으로는 규칙이 맞는데 실제 연결은 다른 IP로 보일 수 있습니다. 이때는 (1) fake-ip-filter에 해당 이름을 넣을지, (2) Meta 관련 이름만 특정 nameserver로 보낼지, (3) TUN으로 트래픽을 모을지 중 하나를 골라 한 축으로 정렬하는 것이 중요합니다.

IPv6 우선 경로나, Wi-Fi와 이동통신을 바꿀 때만 증상이 달라지면 이중 스택·회선별 DNS도 함께 확인하세요.

TUN·앱 경로: 브라우저와 시스템이 다를 때

Android에서는 앱별 경로가 앱별 프록시 가이드에서 정리한 것처럼 OS 정책에 따라 달라집니다. Meta 앱이 시스템 VPN을 완전히 따르지 않으면, 브라우저만 고쳐도 앱은 그대로일 수 있습니다. 데스크톱에서도 브라우저 확장·별도 프록시가 Threads만 우회하면 Clash 규칙과 경쟁합니다. 테스트할 때는 가능한 한 Clash 한 벌만 켜 재현하는 것이 원인 분리에 유리합니다.

Windows에서 TUN을 켠 뒤 전체 인터넷이 끊기면 방화벽·다른 VPN과의 충돌을 먼저 정리합니다. Threads만이 아니라 시스템 전반 증상인지 구분하세요.

주의

지역 법령·서비스 약관·기관 보안 정책을 위반하는 우회를 돕는 목적의 설명은 하지 않습니다. 이 글은 합법적으로 접근 권한이 있는 네트워크에서 기술 경로 불일치로 생기는 로딩 문제를 줄이는 데 한합니다.

점검 순서 체크리스트

  1. Connections 로그에 찍힌 Threads 관련 FQDN을 적고, 그보다 넓은 규칙이 위에서 먼저 잡히지 않았는지 확인합니다.
  2. threads.net과 정적·API 축(cdninstagram.com 등)이 동일한 전략 그룹으로 나가는지 확인합니다.
  3. instagram.com·fbcdn.net을 넣었다면 다른 Meta 서비스에 미치는 범위를 수용할 수 있는지 다시 봅니다.
  4. Fake-IP·스플릿 DNS 조합에서 해석 결과가 어긋나지 않는지 YAML과 대조합니다.
  5. 브라우저와 공식 앱을 나누어, 어느 쪽에서만 재현되는지 범위를 좁힙니다.
  6. TUN·시스템 프록시 중 무엇을 쓰는지 한 가지로 고정하고 다른 VPN과 중복이 없는지 봅니다.
  7. 노드를 바꾸기 전에 규칙 순서·DNS를 먼저 맞췄는지 확인합니다.

정리

Meta Threads 웹이 threads.net만 프록시되고 Meta CDN 축이 DIRECT로 갈라지면 흰 화면·무한 로딩이 자주 납니다. PROXY_THREADS 같은 전용 그룹에 threads.net·cdninstagram.com 등을 묶고, 로그로 확인된 API·CDN 이름을 보강하며, instagram.com·fbcdn.net처럼 범위 큰 접미사는 정책에 맞게 좁히면 같은 노드에서도 체감이 달라질 수 있습니다.

규칙을 손볼 때마다 날짜와 변경 요약을 남겨 두면 이후 비교가 쉽습니다. 클라이언트는 공식 배포 경로에서 확인하는 것이 안전합니다. → Clash를 무료로 내려받아 프로필을 맞춘 뒤, 로그에 나온 실제 호스트부터 Threads 전용 규칙을 다시 점검해 보시기 바랍니다.