증상: 화질은 올라갔는데 자꾸 멈출 때
1080p에서는 괜찮다가 4K나 VP9·AV1 등 고압축 코덱에서만 버퍼링이 심해지는 패턴은 대역폭 자체보다 “세그먼트 다운로드가 끊기거나 다른 출구로 갈라진다”는 신호일 때가 많습니다. 브라우저 개발자 도구의 네트워크 탭을 열어 보면 googlevideo.com·ytimg.com·때로는 gstatic.com·Google API 접두사가 동시에 뜨는데, 이 중 일부만 직접 연결(DIRECT)이고 일부만 프록시를 타면 TLS 세션이나 지역 캐시 엣지가 엇갈려 재생 타이밍이 흔들립니다. 반대로 “전부 프록시”로 두었는데 DNS만 상위 공유기로 새 나가면 FakeIP와 실제 응답이 달라져 규칙이 빗나가기도 합니다. 먼저 어떤 호스트가 어떤 정책에 걸리는지를 로그로 확인하는 편이 빠릅니다.
시스템 프록시만 켠 상태에서 브라우저는 따라오지만, 일부 앱·셋톱은 시스템 설정을 무시합니다. 이때는 Clash Verge Rev TUN 모드 가이드처럼 트래픽이 코어를 통과하도록 한 뒤 분류 규칙을 적용하는 편이 일관됩니다. Windows 초기 설치는 Windows용 Clash 설치 가이드를 먼저 밟으면 실수가 적습니다.
이 글은 YouTube “요금제 리뷰”가 아닙니다
광고 차단·오프라인 저장·화질 상한은 제품 정책과 단말 성능의 영향이 큽니다. 여기서 다루는 것은 로컬 프록시 스택입니다. 즉, 스트리밍에 필요한 도메인이 어떤 정책 그룹으로 매핑되는지, DNS가 규칙과 같은 이름을 돌려주는지, HTTPS·QUIC에서 목적지가 IP로만 보일 때 Sniffer가 필요한지입니다. 이 관점을 유지하면 다른 OTT나 라이브 플랫폼에도 같은 절차를 옮길 수 있습니다.
1관측으로 동영상·CDN 호스트 잡기
고정된 “완벽한 목록”보다 본인 세션에서 실제로 열린 이름을 우선합니다. 데스크톱 브라우저에서는 네트워크 탭에 googlevideo·videoplayback·ytimg 등을 필터링해 보세요. 모바일·앱은 Clash 연결 로그나 웹 패널에서 동시에 열린 행을 확인하는 방식이 현실적입니다. 지역·ISP에 따라 엣지 호스트 문자열이 달라질 수 있으니, 구독에 포함된 GEOSITE 태그가 있다면 youtube·google류가 실제 매칭되는지 로그로 한 번 확인하는 것이 안전합니다. 너무 넓은 DOMAIN-SUFFIX,google.com 한 줄은 검색·메일까지 한꺼번에 끌고 가므로, 스트리밍만 좁히고 싶다면 관측된 하위 접미사를 위에 두는 편이 낫습니다.
“UI는 되는데 영상만 안 된다”면 대개 *.googlevideo.com 또는 인접 CDN 줄이 빗나갔거나, 해당 연결이 QUIC(UDP)로만 나가 규칙·노드 정책과 어긋난 경우를 의심합니다. 이 경우 브라우저에서 QUIC 실험 플래그를 잠시 끄거나, 코어 쪽에서 QUIC 처리 방식을 문서와 맞춰 점검해 보는 것이 진단에 도움이 됩니다.
2분류 규칙 최소 예시(비디오만 프록시)
아래는 설명용 illustration입니다. PROXY 자리에는 자신의 정책 그룹 이름을 넣고, 상위에 이미 GEOIP·MATCH가 있다면 순서를 조정하세요. 실제 환경에서 로그로 본 이름을 추가·삭제하세요.
# Minimal illustration — replace PROXY with your policy group
rules:
- DOMAIN-SUFFIX,googlevideo.com,PROXY
- DOMAIN-SUFFIX,ytimg.com,PROXY
- DOMAIN-SUFFIX,youtube.com,PROXY
- DOMAIN-SUFFIX,ggpht.com,PROXY
# Optional: narrow API hosts seen in your logs
- DOMAIN-SUFFIX,googleapis.com,PROXY
- MATCH,DIRECT
RULE-SET으로 묶어 두면 구독 측에서 갱신할 때 한 파일만 교체하면 됩니다. 다만 범용 세트가 과하게 넓으면 원치 않는 Google 트래픽까지 프록시에 태울 수 있으니, “스트리밍만”이 목표라면 좁은 사용자 규칙과 로그 기반 확장이 균형이 좋습니다. Rule Provider 선택 기준은 ACL4SSR 비교 글을 참고하세요.
브라우저·QUIC·스니퍼
HTTPS 연결이 IP로만 보이면 DOMAIN·GEOSITE 줄이 적중하지 않을 수 있습니다. Meta 계열에서는 Sniffer로 SNI·QUIC·HTTP 호스트를 복원한 뒤 규칙 순서를 맞춥니다. FakeIP와 병행할 때는 fake-ip-filter에 로컬·필수 이름을 넣고, 스니퍼 결과가 기대와 다르면 한 번에 여러 옵션을 바꾸지 말고 단계별로 검증하세요.
3정책 그룹·노드와 고비트레이트
4K는 순간 대역이 크게 튀고 세그먼트 단위로 버스트가 이어집니다. 지연 숫자만 낮아도 패킷 손실이 있으면 체감 버퍼링이 커집니다. url-test·fallback류 그룹으로 자동 전환을 두면 세션 끊김을 줄일 수 있습니다. 다만 “영상만” 그룹을 따로 두고 나머지 일상 트래픽은 기존 분류를 유지하는 편이, 과금·안정성 측면에서 부작용이 적습니다. 노드 지역과 실제 googlevideo 엣지 지역이 어긋나면 캐시 히트가 나빠질 수 있으니, 문제가 지속되면 동일 프로필에서 출구 지역을 바꿔 A/B 비교해 보는 것도 방법입니다.
4DNS·FakeIP·DoH 정합
OS·공유기·브라우저 보안 DNS가 동시에 켜져 있으면 Clash의 DNS 설정과 엇갈려 규칙 매칭이 흔들립니다. Meta 코어에서는 상위 리졸버를 DoH·DoT로 통일하고, FakeIP 사용 시 실제 응답과 필터 목록을 문서 순서대로 맞추는 편이 안전합니다. 구체적인 체크리스트는 Meta 코어 DNS 유출 방지 가이드를 따르세요. “DNS만 바꿨는데 갑자기 전부 느려졌다”면, 필터나 업스트림이 차단 목록을 과하게 태우고 있지 않은지도 함께 보세요.
요약: 분류 규칙은 클라이언트·코어가 본 도메인과 DNS 경로가 같을 때 가장 잘 맞습니다. 4K 문제를 볼 때는 googlevideo 줄과 DNS·FakeIP를 한 세트로 생각하세요.
5다른 글과의 역할 분담
Steam 스토어 글은 PC 런처·커뮤니티·CDN 분기에 가깝고, 본문은 YouTube·동영상 CDN에 초점을 둡니다. ChatGPT·Manus 등 AI 웹 글과는 같은 “규칙 적중 → DNS → 노드” 방법론이지만 제품 축이 다릅니다. 전체 지도는 문서·설정 허브와 함께 보면 빠르게 훑기 좋습니다.
6검증: 규칙 적중 → DNS → 노드
변경 후에는 한 번에 한 변수만 바꿉니다. 먼저 연결 로그에서 문제가 된 호스트가 어떤 규칙 줄·어떤 정책 그룹에 매칭됐는지 확인합니다. 이어서 같은 이름에 대해 DNS 응답이 FakeIP·실 IP 중 무엇을 기대하는 설정인지 점검합니다. 마지막으로 다른 노드·다른 출구 지역과 대조해 “규칙 문제인지 품질 문제인지”를 가릅니다. 시스템 프록시만 켠 상태와 TUN을 켠 상태를 번갈아 보면 앱이 프록시를 무시하는지 빠르게 확인할 수 있습니다.
계정·시청 기록이 섞인 요청은 로그에 남기지 않도록 주의하고, 재생 실패 시 HTTP 상태·TLS 오류 문구를 구분해 기록하면 원인 문장이 짧아집니다.
준수: 소속 기관·국가의 네트워크 규정과 서비스 약관을 준수하세요. 본문은 기술적 네트워크 구성 설명이며, 권리를 침해하는 우회 목적에 사용하지 마세요. 엔드포인트 예시는 공개 정보·본인 관측을 기준으로 하되 변경될 수 있습니다.
마치며
YouTube 4K·고비트레이트 재생은 단일 도메인이 아니라 세그먼트·이미지·API가 갈라진 CDN 구조를 가정해야 버퍼링 원인을 짧게 설명할 수 있습니다. Clash·Mihomo에서는 동영상 관련 접미사를 분류 규칙으로 모으고 나머지는 직접 연결에 두는 그림이 대역·지연 균형에 자주 유리합니다. 그 위에 DNS·FakeIP·필요 시 DoH를 맞추고, Sniffer로 이름 정보가 규칙까지 도달하는지 확인하면 “화질만 올렸는데 자꾸 멈춘다”는 상황에서 조치 순서가 명확해집니다.
프로필·규칙·DNS를 한 화면에서 다루기 쉬운 클라이언트는 일상 트래픽과 스트리밍을 같은 기기에서 쓸 때 실수를 줄이는 데 도움이 됩니다. 유사 도구보다 설정 축을 맞추기 편한 편이라, 장시간 시청 환경에서 체감 차이가 납니다.