1. “계속 로딩”·댓글이 비는 증상부터 나누기
브라우저에서 Reddit을 쓸 때 자주 쓰는 표현—피드는 보이는데 스크롤하다 멈춤, 글은 열리는데 댓글 칸만 스피너, 투표·작성이 안 되는 경우, 썸네일만 비어 있고 본문은 뜨는 경우 등—은 한 문장 “느리다”로 묶이기 어렵습니다. Clash를 RULE 모드로 쓰면 요청마다 도메인이 달리고, 첫 번째로 매칭된 규칙 줄이 출구를 정합니다. reddit.com만 프록시 그룹 A에 넣고 redd.it·redditmedia가 넓은 MATCH에서 다른 정책으로 빠지면, 눈에 보이는 UI와 실제 XHR·이미지·썸네일이 다른 IP·지연을 밟는 반쪽 경로가 됩니다. 2026년에도 “커뮤니티+정적+API”를 한 묶음으로 다루지 않고 노드 핑만 낮추는 글을 보면, 같은 구독이라도 사례가 크게 갈라지는 이유를 설명하기 어렵습니다.
또한 모바일 앱·PWA·구형 old.reddit 레이아웃은 기본으로 요청하는 호스트 조합이 조금씩 달라, “웹만 문제”·“앱은 된다” 같은 패턴이 나옵니다. 증상을 재현할 때는 가능하면 동일 브라우저·동일 글로 고정하고, 개발자 도구 네트워크 탭에서 실제로 실패·지연한 FQDN을 적어 두는 것이 이후 규칙 분류에 직접 이어집니다.
2. YouTube·스트리밍·생성형 API 글과 겹치지 않는 이유
YouTube 글은 googlevideo.com으로 이어지는 대용량 스트리밍·세그먼트 경로에 맞춰 있습니다. Reddit은 광고·추천·실시간성이 있긴 해도, 체감의 대부분은 HTML·JSON·작은 정적·이미지·짧은 비디오에 가깝고, 썸네일·외부 임베드 URL이 preview.redd.it·외부 사이트로 퍼집니다. 따라서 “googlevideo용 접미사만 추가하면 커뮤니티 사이트도 해결”이라는 가정은 위험합니다. 반대로 Hugging Face나 대형 CDN 다운로드 글과 비교할 때는, Hugging 쪽이 LFS·대용 전송 비중이 크다는 점이 다릅니다. Reddit에선 웹 로딩·댓글·GraphQL이 같은 “대화” 안에서 어긋나는지를 먼저 보는 편이 낫습니다.
또 Fastly·기타 CDN은 호스트이름이 브랜드와 떨어진 경우가 많아, 규칙에 “Reddit”이라는 단어만 넣기보다 본인 환경에서 관측한 FQDN을 기준으로 잡는 것이 안전합니다. 공개 룰셋을 가져왔다면, 그 안에서 Reddit 관련 줄이 구독 규칙보다 아래에 밀렸는지(매칭이 안 나는지)를 로그로 확인해야 합니다.
3. 웹·API·정적·미디어가 갈리는 흐름(개념)
실제 풀과 시점에 따라 달라지므로 절대 고정 목록이 아니라, 브라우저에서 관측한 이름을 맞추는 것이 전제입니다. 흔히 등장하는 축은 다음과 같이 나누어 볼 수 있습니다. 첫째, 메인 UI·로그인·서브도메인의 HTML과 스크립트—www.reddit.com·reddit.com·old.reddit.com 등. 둘째, GraphQL·내부 API성 호출—gql.reddit.com 등(실제 FQDN은 클라이언트 버전에 따름). 셋째, 짧은 링크·이미지 프리뷰—redd.it, preview.redd.it, external-preview.redd.it, i.redd.it, v.redd.it 류. 넷째, 정적·스타일·위젯—styles.redditmedia.com, redditstatic.com 류. 이들이 서로 다른 노드로 터널되면, 한쪽은 빠른데 댓글 스트림·투표만 타임아웃하는 식의 불균형이 납니다.
댓글이 “안 보인다”는 말 뒤에 숨는 것
댓글은 단순 HTML 한 번이 아니라 목록·정렬·모더레이션 상태에 맞는 데이터가 연속으로 붙습니다. 일부는 WebSocket·롱풀·페이지네이션에 가깝고, 쿠키·로그인 세션이 reddit.com 한쪽에만 일관되면 나머지 요청이 실패해도 “빈 댓글”처럼 보일 수 있습니다. Clash 로그에서 어떤 도메인이 먼저 실패·리셋됐는지 잡는 것이 핵심이며, TLS·SNI 쪽은 TLS 글과 병행하면 원인이 좁혀집니다.
4. Fastly·엣지와 “왜 캐시 도메인을 규칙에 넣는가”
글로벌 엣지·CDN은 지연을 줄이기 위해 PoP(엣지) 단위로 경로를 나눕니다. 서비스가 Fastly를 쓰는 경우, 브라우저 개발자 도구에서 응답 헤더나 TLS 인증서 체인을 보면 “어느 계열에 붙었는지” 힌트를 얻을 수는 있으나, 프록시 관점에선 “브랜드 도메인이 아닌, 실제로 연결에 쓰인 SNI/호스트”를 규칙에 쓰는 것이 맞습니다. 분류 시에는 (1) 앱/브라우저가 쓰는 FQDN 전체, (2) DOMAIN-SUFFIX로 잡을지 키워드로 잡을지(오탐), (3) GEOIP·지역 DIRECT가 위에서 먼저 매칭되는지—세 가지를 동시에 봅니다. 중국 본토 등 직접 연결을 섞는 프로필이면 GeoIP 글과의 순서 충돌도 점검합니다.
5. Clash 규칙으로 Reddit 관련 축을 한 그룹에
Clash / Mihomo 계열은 위에서 아래로 첫 매칭이 적용됩니다. Reddit·주변 호스트를 한 정책 그룹(예: REDDIT-UI)에 모으려면, 자주 쓰는 DOMAIN-SUFFIX를 넓은 MATCH보다 위에 두는 패턴이 일반적입니다. 아래는 이해를 돕는 스켈레톤이며, 실제 환경·구독 세트·시점에 맞게 FQDN을 덧붙이거나 줄여야 합니다.
proxy-groups:
- name: REDDIT-UI
type: select
proxies: [DIRECT, YourNodeA, ...]
rules:
- DOMAIN-SUFFIX,reddit.com,REDDIT-UI
- DOMAIN-SUFFIX,redd.it,REDDIT-UI
- DOMAIN-SUFFIX,redditstatic.com,REDDIT-UI
- DOMAIN-SUFFIX,redditmedia.com,REDDIT-UI
- MATCH,Others
실제로는 preview.redd.it·i.redd.it·gql.reddit.com 등이 DOMAIN-SUFFIX,redd.it·DOMAIN-SUFFIX,reddit.com로 함께 잡히는 경우가 많아, 캡처한 FQDN에 맞춰 접미사를 덧붙이면 됩니다. DOMAIN-KEYWORD,reddit은 범위가 넓어 오탐이 나기 쉬우니, 이슈가 생기면 접미사 위주로 좁힙니다. 구독 rule-provider가 상위에서 이미 Reddit을 보내고 있다면, 자신이 추가한 USER_RULE이 그보다 위에 있어야 덮어씁니다.
6. 정책 그룹·노드: url-test와 “한 출구” 실험
노드 선택을 최저 핑만으로 고르면, url-test가 짧은 주기로 출구를 바꿀 때 세션·쿠키와 엇갈리는 느낌이 날 수 있습니다. 커뮤니티 사이트는 “한 번에 느리다”기보다 특정 요청만 실패하는 경우가 있어, 문제 재현 구간에 한해 select로 한 노드에 고정하고 동일 스레드를 열어 비교하는 방식이 해석에 유리합니다. 구독 풀 안에서 지리적으로 동일한 출구를 쓰는지도 함께 봅니다. 혼잡한 공용 노드는 TCP 재전송이 누적돼 댓글 JSON만 늦게 붙는 것처럼 보이기도 합니다.
url-test·interval·tolerance 튜닝이 필요하면 해당 글을 보조로 두고, “규칙으로 묶인 출구”만이 아닌 전체 모드(GLOBAL·DIRECT) 실수는 튜토리얼 흐름으로 먼저 제외합니다. LAN·혼합 포트를 쓰는 경우 Mixed Port와 충돌이 없는지도 점검합니다.
7. DNS·fake-ip·DoH가 댓글·피드를 망치는 방식
규칙이 맞아 보여도, DNS 응답이 먼저 갈리면 애플리케이션은 Clash 터널에 도달하기 전에 멈춥니다. fake-ip 환경에서는 가상 IP 매핑과 OS·브라우저 DoH가 동시에 켜져 “간헐적으로만 댓글이 비는” 패턴도 나올 수 있습니다. reddit.com과 이미지·미디어 도메인이 서로 다른 리졸버로 풀리면 엣지까지의 RTT·경로가 달라져, 한쪽은 빠른데 다른 쪽만 타임아웃으로 보이기도 합니다. fake-ip 글의 filter·캐시·폴백 절차를 병행하세요. 스니퍼·HTTPS 이슈는 이 글과는 다른 축이므로 스니퍼 문서를 참고해 도메인 제외를 좁힙니다.
8. 운영 중에도 따라갈 점검 순서
다음 순서는 재현·배포·원격 지원에 모두 쓸 수 있게 짧은 플레이북으로 둡니다.
- 모드:
RULE인지, 실수로GLOBAL·DIRECT로 고정됐는지 확인합니다. - 로그: 댓글이 비는 시각에 어떤 도메인·어떤 규칙이 잡혔는지 캡처합니다.
- FQDN 목록: 네트워크 탭에서 실패·지연이 큰 요청의 이름을 적어
DOMAIN-SUFFIX에 반영합니다. - 노드 고정:
url-test를 잠시 끄고select로 동일 스레드·동일 댓글을 재시도합니다. - DNS 단일화: Clash·OS·브라우저 DoH를 정리한 뒤 fake-ip·필터를 점검합니다.
- TUN·스플릿: 전역 터널이면 TUN·라우팅을, 스플릿이면 제외 도메인을 대조합니다.
프로필을 손댄 뒤에는 브라우저 캐시·서비스 워커·확장을 분리하려고 시크릿 창·다른 프로필에서도 한 번 더 확인하는 편이 좋습니다. YAML을 Git으로 관리하면 “어떤 접미사를 언제 넣었는지”를 추적할 수 있어 재발 분석에 유리합니다.
10. 증상별로 무엇을 먼저 볼지
아래는 Reddit 웹·앱을 쓸 때 웹 로딩·댓글 이슈를 Clash 관점에서 정리한 표입니다.
11. 맺음말
Reddit는 커뮤니티 HTML·댓글·Fastly 등 CDN을 거친 정적·미디어가 한 화면에 겹쳐 있어, “한 도메인만 프록시”로는 웹 로딩·댓글 붙음이 쉽게 엇갈릴 수 있습니다. Clash 규칙 분류로 관측한 FQDN을 정책 그룹에 모으고, 노드·DNS를 같은 세션 기준으로 맞추면, 스피너만 돌고 댓글이 비는 식의 증상을 네트워크 층에서 체계적으로 좁힐 수 있습니다. 본문은 약관 위반·지역 제한 우회가 아니라, 경로 일관성 점검에 초점을 둡니다.
공유 규칙 세트를 쓰더라도 본인 프로필의 매칭 순서·구독 갱신 시점에 따라 언제든 달라질 수 있으니, 연결 로그를 읽는 습관이 유지보수 비용을 줄여 줍니다. 최신 UI의 연결·규칙 뷰가 읽기 쉬운 Mihomo 계열 클라이언트는 이런 도메인이 많이 갈라지는 서비스에 특히 잘 맞습니다.
설치 파일은 다운로드 페이지에서 받는 것이 안내·검증 측면에서 분명하고, GitHub 쪽은 빌드·이슈·라이선스 확인용으로 두면 혼선이 적습니다.