1. 웹에서 자주 보는 증상부터 나누기
YouTube 웹을 쓸 때 네트워크 쪽에서 먼저 살펴볼 만한 패턴은 대략 네 가지입니다. 첫째, 홈·검색·채널 페이지는 빠른데 재생 버튼 이후만 버퍼링이 길다. 둘째, 화질을 낮춰도 개선이 거의 없고 특정 시간대에만 악화된다. 셋째, 한 탭은 재생되는데 다른 탭·시크만 실패한다. 넷째, 브라우저는 정상인데 다른 앱의 시스템 프록시 경로와 섞여 증상이 달라진다. 이때 “노드 ping만 낮추면 된다”는 가정은 위험합니다. youtube.com으로 보이는 UI 요청과, 실제 미디어가 나가는 googlevideo.com 요청이 서로 다른 규칙 줄에 매칭되면 한쪽만 터널을 타는 반쪽 경로가 되기 쉽습니다.
2026년 현재에도 긴 동영상·크리에이터 플랫폼 수요는 높고, 사용자 커뮤니티에서는 “웹만 끊긴다”“특정 지역 CDN이 느리다” 같은 검색이 이어집니다. 본문은 그런 맥락에서 분류 규칙과 출구 일관성을 맞추는 데 초점을 둡니다. 계정 제한·프리미엄 여부·지역 가용 콘텐츠는 네트워크 설정만으로 해결되지 않는 경우가 많으니, 증상을 계정 정책과 연결 경로로 나누어 생각하는 것이 좋습니다.
클라이언트 선택과 공통 문법은 Windows용 Clash 비교와 설정 가이드를 함께 보면 프로필 수정 속도가 빨라집니다.
2. Google Gemini·API 글을 그대로 가져오면 안 되는 이유
저장소의 Gemini·Google API 글은 gemini.google.com·generativelanguage.googleapis.com 등 생성형 API·챗 UI 호스트를 한 출구에 묶는 데 유리합니다. 반면 YouTube 웹 재생은 동일 브랜드 안에서도 대용량 스트리밍·적응 화질·세그먼트 요청이 추가로 등장하고, 호스트 이름이 googlevideo.com처럼 UI 도메인과 완전히 분리되는 경우가 많습니다. 따라서 “Google 관련 도메인을 한 줄로 묶었으니 재생도 된다”는 가정만으로는 부족하고, 미디어 전용 접미사를 규칙 상단에서 명시적으로 잡아 주는 편이 안전합니다.
또한 url-test 그룹이 짧은 주기로 최저 지연 노드를 바꾸면, 세그먼트 요청마다 관측 IP나 경로가 흔들려 버퍼 상태 예측이 어려워질 수 있습니다. 재생 문제를 재현할 때는 한동안 수동 select로 노드를 고정하고, 동일 영상·동일 화질로 비교 실험하는 방식이 해석에 유리합니다.
googlevideo·ytimg 등 실제로 나가는 이름을 적어 두세요. 구독 규칙 세트를 쓰더라도 본인 환경에서 관측한 FQDN을 덧붙이면 업데이트 이후에도 유지보수 비용이 줄어듭니다.
3. 웹 재생이 거치는 호스트(개념)
공개 동작과 브라우저 패킷을 합치면, YouTube 웹 흐름은 대략 다음 축으로 나뉩니다. 페이지 뼈대·스크립트·계정 연동은 youtube.com·youtu.be 리다이렉트·google.com 일부가 담당합니다. 썸네일·UI 이미지에는 ytimg.com·ggpht.com 류가 자주 등장합니다. 실제 비디오 바이트는 googlevideo.com 호스트명 아래 세그먼트로 나뉘어 오가는 경우가 많고, 적응 스트리밍 때문에 짧은 시간에 여러 하위 이름으로 요청이 퍼질 수 있습니다. 일부 기능은 googlevideo.com 외에도 Google 인프라의 다른 엣지 이름을 쓸 수 있으니, “한 번 잡아 둔 목록”만 믿지 말고 문제가 난 순간의 네트워크 로그를 기준으로 삼는 것이 좋습니다.
왜 UI는 되는데 재생만 느리게 느껴질까
HTML과 JSON은 상대적으로 작고, 미디어 세그먼트는 크기와 지속 시간이 크게 다릅니다. 규칙이 youtube.com만 프록시 그룹에 넣고 googlevideo.com은 광범한 MATCH 줄에서 다른 정책으로 빠지면, 사용자는 “페이지는 열리는데 영상만 안 나온다”는 체감을 하게 됩니다. 반대로 미디어만 특정 노드로 보내고 인증·쿠키가 필요한 호스트는 직접 연결이면 로그인 세션과 충돌할 수 있어, 한 세션 안에서의 일관성을 우선합니다.
4. 라이브와 VOD의 네트워크 차이(요약)
라이브 스트림은 지연을 줄이기 위해 세그먼트 주기·버퍼 정책이 VOD와 다르고, 채팅·메타데이터용 WebSocket 등 부가 연결이 붙을 수 있습니다. 온디맨드(VOD) 재생은 긴 파일을 여러 Range 요청으로 나누며, 시크 시 새 엣지로 붙는 패턴도 흔합니다. 둘 다 결국 googlevideo 계열 비중이 크지만, 라이브에서만 간헐적으로 실패한다면 UDP·QUIC 경로나 다른 VPN과의 충돌을 함께 의심해 볼 수 있습니다. 여기서는 OS·클라이언트별 예외를 모두 나열하기보다, 동일 영상을 VOD로 재생했을 때와 라이브만 문제인지를 먼저 분리해 보는 것을 권장합니다.
TUN 모드나 전역 터널을 쓰는 경우 TUN·라우팅 글과 겹치는지도 확인합니다. 브라우저만 시스템 프록시를 쓰는 구성이라면 확장·DoH 설정이 코어 DNS와 엇갈리지 않는지 함께 봅니다.
5. Clash 규칙 분류로 YouTube·미디어 호스트 묶기
Clash(Mihomo 계열)에서는 RULE 모드에서 위에서 아래로 첫 매칭이 적용됩니다. YouTube 관련 트래픽을 한 정책 그룹(예: YT-MEDIA)에 모으려면, 미디어에 특히 중요한 DOMAIN-SUFFIX를 위에 두고 넓은 규칙은 아래에 두는 순서가 안전합니다. 아래는 이해를 돕기 위한 예시 스켈레톤이며, 실제 환경·구독 세트·시점에 따라 하위 도메인이 달라질 수 있으니 반드시 본인이 캡처한 호스트로 바꾸세요.
rules:
- DOMAIN-SUFFIX,googlevideo.com,YT-MEDIA
- DOMAIN-SUFFIX,youtube.com,YT-MEDIA
- DOMAIN-SUFFIX,ytimg.com,YT-MEDIA
- DOMAIN-SUFFIX,ggpht.com,YT-MEDIA
- DOMAIN-SUFFIX,googleusercontent.com,YT-MEDIA
- MATCH,OthersDOMAIN-KEYWORD,googlevideo처럼 짧은 키워드는 편하지만 오탐이 나기 쉬워, 문제가 생기면 접미사 위주로 좁히는 것이 좋습니다. 구독에서 가져온 대형 규칙 세트가 먼저 매칭되면 아래에 둔 YouTube 전용 줄이 실행되지 않을 수 있으므로, 연결 로그에서 실제로 어떤 줄이 선택됐는지 확인하세요. proxy-groups에 YT-MEDIA를 정의하지 않으면 의도와 다른 폴백으로 떨어질 수 있습니다.
6. 노드 선택: 버퍼링에 특히 민감한 지점
노드 선택은 단순 최저 ping만으로 고르기 어렵습니다. 스트리밍은 초 단위로 이어지는 TCP·TLS 세션과 대역폭이 중요하고, 혼잡한 공용 노드에서는 재전송이 늘어 체감이 크게 나빠집니다. 같은 구독이라도 피어링 구간이 다르면 지연 분산과 실제 처리량이 달라지므로, 규칙으로 묶인 트래픽만 별도 그룹으로 빼 실험하는 편이 해석이 쉽습니다. 장시간 시청·고화질에서는 url-test가 자주 출구를 바꾸지 않도록 주의하세요.
LAN에서 Mixed Port를 열어 둔 경우 Mixed Port·방화벽 가이드와 충돌이 없는지, 다른 VPN과 동시에 켜 두지 않았는지도 함께 확인합니다. TLS 관련 로그가 반복된다면 TLS·SNI 점검 글을 병행해 원인을 좁힐 수 있습니다.
7. DNS·fake-ip·모드가 재생을 망치는 방식
규칙이 맞아 보여도 DNS 조회가 먼저 실패하면 애플리케이션은 프록시를 타기 전에 멈춥니다. fake-ip 모드에서는 도메인과 가상 IP 매핑 타이밍이 민감하고, OS·브라우저 DoH·사내 리졸버가 동시에 개입하면 “간헐적으로만 재생된다”는 패턴이 나올 수 있습니다. youtube.com과 googlevideo.com이 서로 다른 리졸버로 풀리면 엣지까지의 경로가 달라져 체감이 달라지기도 합니다. 자세한 분기는 fake-ip·DNS 트러블슈팅 글을 참고하세요.
점검 순서는 (1) Clash DNS 패널의 리졸버·폴백, (2) 운영체제 캐시, (3) 브라우저 전용 DoH입니다. DIRECT로 나가야 할 내부 호스트가 오탐으로 프록시에 탄 경우에도 스피너만 도는 것처럼 보일 수 있으니, 코어 로그에서 어떤 규칙에 매칭됐는지 습관적으로 읽는 것이 중요합니다. 모드 전환 실험은 튜토리얼과 병행하면 부담이 적습니다.
8. 재현 가능한 점검·설정 순서
운영 중에도 따라갈 수 있게, 아래 순서를 기본 플레이북으로 두면 좋습니다.
- 모드 확인:
RULE인지, 실수로GLOBAL·DIRECT로 고정돼 있지 않은지 봅니다. - 매칭 로그: 재생이 끊긴 시각에 어떤 규칙이 선택됐는지 캡처합니다.
- 호스트 목록: 네트워크 탭에서 지연·실패가 큰 요청의 FQDN을 적어
DOMAIN-SUFFIX로 추가합니다. - 노드 고정:
url-test를 잠시 끄고 수동 노드로 동일 시나리오를 재현합니다. - DNS 정렬: Clash·OS·브라우저 DoH 충돌을 제거한 뒤 다시 시도합니다.
- TUN·예외: 전역 터널을 쓰는 경우 로컬 서비스 예외 목록을 문서와 대조합니다.
변경 후에는 브라우저 강력 새로고침, 가능하면 다른 브라우저 프로필에서도 한 번 더 확인해 캐시·확장 영향을 분리하세요.
10. 증상별 자가 점검
아래 표는 YouTube 웹 재생 환경에서 무엇을 먼저 볼지 정리한 것입니다.
| 증상 | 의심 지점 | 조치 |
|---|---|---|
| UI는 빠른데 재생만 버퍼링 | googlevideo·CDN 규칙 누락, 다른 정책으로 매칭 |
미디어 FQDN 확인 후 접미사 규칙 추가·순서 조정 |
| 간헐적 끊김·타임아웃 | 혼잡한 출구, DNS 흔들림, url-test 전환 | select·fallback 실험, DNS 단일화 |
| 저화질로도 개선 없음 | 대역·패킷 손실, 노드 품질 | 동일 규칙 그룹에서만 노드 교체 비교 |
| 라이브만 불안정 | 추가 WebSocket·다른 VPN·QUIC 경로 | VOD와 비교, TUN·확장 끄고 재현 |
증상이 계정·프리미엄·지역 정책과 맞물리면 지원 채널에 보낼 재현 정보를 함께 모아 두면 응답이 빨라집니다.
11. 요약
YouTube 웹 재생은 youtube.com UI와 googlevideo.com 미디어가 분리되어 있어, 한 줄짜리 “Google 프록시”보다 도메인 기준 규칙 분류와 노드·DNS 일관성이 체감 안정성을 좌우합니다. 화면이 멈추거나 스피너만 돌 때도 네트워크 측에서는 경로 일관성·DNS·출구 전환을 먼저 의심해 볼 수 있습니다. 본문 목적은 “차단 해제” 같은 말로 끝내는 것이 아니라, 영상 전용 호스트를 규칙으로 묶어 점검 순서를 갖추는 데 있습니다.
공유 규칙 세트를 가져왔더라도 본인 프로필에서의 매칭 순서는 직접 확인하는 것이 안전합니다. 연결 기록과 규칙 테스트가 읽기 쉬운 최신 Mihomo 계열 클라이언트를 쓰면 호스트가 늘어나는 서비스에 맞춰 유지보수하기에도 유리합니다.
설치 패키지는 공식 다운로드 페이지에서 받는 것이 혼선이 적고, 오픈 소스 저장소는 빌드·이슈 확인용으로 참고하면 됩니다.
→ Clash를 무료로 내려받아 YouTube·googlevideo용 규칙 분류와 노드 정책을 직접 맞춰 보세요