증상: 재생 끊김·화질 정체·Premium·지역 메시지가 엇갈릴 때
YouTube 클라이언트는 한 화면 안에서도 여러 단계의 백엔드 호출을 이어 붙입니다. 홈·구독·Shorts 같은 표면 UI, 검색·추천과 연결된 API, 썸네일·폰트·번들 자산을 끌어오는 CDN, 그리고 실제 재생 협상과 세그먼트 전송에 쓰이는 googlevideo.com 계열 엣지까지 도메인이 갈라집니다. 그중 일부만 스트리밍 노드가 있는 정책 그룹을 타고, 나머지는 느린 직접 회선이나 다른 지역 출구에 남으면 목록은 빠른데 재생만 버벅이거나, 특정 해상도에서만 멈춘 것처럼 느껴집니다. 전역 프록시로 모두 밀어 넣으면 다른 앱과 대역을 나눠 쓰고, 반대로 youtube.com만 프록시에 두고 googlevideo 접미사를 빠뜨리면 TLS는 열려도 세그먼트가 엇갈려 재생 끊김이 반복됩니다.
Premium·Family·결제 관련 흐름은 Google 계정·결제 프로필과 연결되어 있어, 출구 IP가 바뀌면 「이 지역에서는 제공되지 않습니다」류 안내가 뜨거나, 반대로 재생은 되는데 혜택 배너만 어긋나 보일 수 있습니다. 이는 단순히 화질만 낮아지는 증상과 결이 비슷하지만, YouTube는 계정·광고·스튜디오까지 같은 생태계 안에 묶여 있어 규칙 누락이 버퍼링이 아니라 지역 검출 메시지로 드러나기도 합니다. 관측부터: 문제가 날 때 Clash 라이브 연결 목록을 켠 채 동일 영상을 처음부터 다시 재생하고, 썸네일 로드→재생 버튼→첫 세그먼트까지 붙는 호스트 이름을 순서대로 적어 보세요. youtube.com만 프록시이고 googlevideo.com이 DIRECT인지 같은 표의 균열을 먼저 찾는 것이 빠릅니다.
YouTube 관련 이름 공간(웹·API·CDN·googlevideo)
공급망과 앱·브라우저 채널에 따라 호스트 표는 바뀌지만, 실무에서는 다음과 같은 묶음을 한 스트리밍 정책으로 두는 패턴이 자주 등장합니다. (1) 사용자가 보는 웹·앱 셸과 내비게이션: youtube.com, youtu.be, 모바일 앱 딥링크. (2) Google 계정·동기화·일부 공통 API: google.com, accounts.google.com, apis.google.com, oauth 관련 호스트 — 로그인 단계에서만 필요한 경우가 많아 스트리밍 노드와 동일 출구를 강제할지는 환경마다 다릅니다. (3) 이미지·정적 자산: ytimg.com, ggpht.com, gstatic.com 등. (4) 실제 미디어 세그먼트: googlevideo.com 및 그 하위, 때로는 지역·캐시별로 긴 호스트 이름이 찍힙니다.
Star나 Music 등 인접 제품이 섞여 보여도 Clash 입장에서는 여전히 도메인 규칙으로 출구를 고릅니다. DOMAIN-KEYWORD,youtube처럼 넓게 잡는 방법은 빠르지만 무관한 트래픽까지 끌어올릴 수 있어, 로그로 실명이 확인된 뒤 DOMAIN-SUFFIX를 층층이 쌓는 쪽이 운영에 유리합니다. 구조 설계는 규칙·분류 모범 사례와 맞추고, 스트리밍 전용 줄을 광범한 GEOIP나 광고 목록보다 위에 두세요. 원격 규칙 세트에 geosite:youtube 류 카테고리가 있다면 버전과 출처를 확인합니다. 오래된 세트는 새 엔드포인트를 놓치고, 지나치게 공격적인 리스트는 로그인 단계를 건드려 증상을 바꿀 수 있습니다. 구독 URL이 깨지지 않게 하려면 구독·노드 유지보수에서 다룬 것처럼 규칙 프로바이더 갱신 경로를 안정 경로에 두는 것도 잊지 마세요.
Premium·결제 지역과 재생 경로의 차이
Premium·Family·학생 할인 등은 결제 수단·청구 국가·Google 계정 주소와 연결됩니다. 반면 동영상 재생은 googlevideo 엣지와 CDN 캐시에 더 가깝게 붙습니다. 두 축이 같은 노드 지역을 가리키지 않으면 「결제 메시지는 A국인데 재생 품질은 B국 회선 같다」처럼 느껴질 수 있고, 일부 안내 문구는 출구 IP 기준으로 바뀌기도 합니다. 이 글은 기술적으로 출구를 맞추는 방법을 설명하지만, 서비스 약관상 허용된 이용 방식과는 별개입니다. 계정·결제 프로필을 바꾸기 전에 약관과 Google 지원 문서를 확인하는 것이 안전합니다.
광고 차단·추적 차단 확장이나 기업 프록시가 googlevideo만 부분 차단하면 재생은 되지만 특정 해상도에서만 실패하는 패턴도 나옵니다. Clash 밖의 필터와 도메인 분류가 동시에 걸리면 원인 추적이 어려워지므로, 한 번에 한 겹씩 끄고 라이브 로그를 비교하는 편이 낫습니다.
도메인 규칙·규칙 세트·분류 순서
Clash Meta 계열은 규칙을 위에서 아래로 평가하므로, YouTube에 해당하는 DOMAIN-SUFFIX 묶음이 넓은 MATCH나 다른 대륙 GEOIP보다 먼저 오도록 정렬해야 합니다. 스트리밍 한 줄을 추가했는데도 효과가 없다면, 그보다 위에 있는 다른 줄이 이미 잡아챘는지부터 의심합니다. 광고 차단 목록이 CDN 호스트를 오탐하면 자산만 말라버리는 것과 같습니다.
아래는 이해를 돕는 예시 YAML 조각입니다. 정책 그룹 이름·노드 풀·추가 접미사는 본인 구독과 로그에 맞게 바꿉니다.
Illustrative YAML fragment
rules:
- DOMAIN-SUFFIX,youtube.com,YT
- DOMAIN-SUFFIX,googlevideo.com,YT
- DOMAIN-SUFFIX,ytimg.com,YT
- DOMAIN-SUFFIX,ggpht.com,YT
- DOMAIN-SUFFIX,gstatic.com,YT
- DOMAIN-SUFFIX,google.com,YT
- GEOIP,CN,DIRECT
- MATCH,DIRECT
실제 환경에서는 위 목록보다 더 세분화하거나 오히려 google.com 전체를 한 그룹에 넣지 않는 편이 낫습니다. Google 검색·Gmail까지 같은 출구를 강제하면 일상 업무 트래픽이 불필요하게 길어질 수 있기 때문입니다. 로그인만 분리하고 재생만 YT로 묶는 식으로 조정하는 경우가 많습니다. 새 앱 업데이트 후 갑자기 버퍼가 길어졌다면, 릴리스 직후 로그에 새 호스트가 등장했는지 보고 한 줄씩 정책으로 옮기는 방식이 가장 재현 가능합니다. MATCH가 전부 DIRECT인데 빠진 이름이 있으면 그 호스트만 다른 출구로 새어 지역 검출과 세션이 엇갈릴 수 있습니다.
스트리밍 노드·노드 지역·지역 검출
노드 선택에서 흔한 오해
지연 숫자만 낮은 노드가 항상 끊김 없는 재생으로 이어지지는 않습니다. 장시간 TLS·대역을 안정적으로 유지하는지, 상용망과 콘텐츠망 사이 라우팅이 어떤지가 중요합니다. 데이터센터형 IP는 구독 설명에 「스트리밍」이 있어도 실제 협상이 보수적으로 잡히거나 중간 품질에 머무는 경우가 있습니다. 노드 지역 라벨이 계정·결제 프로필과 크게 어긋나면 일부 안내 문구나 실험 기능 표시가 기대와 다를 수 있으니, 의도한 리전과 출구를 맞추는 것이 지역 검출 측면에서도 안전합니다.
정책 그룹과 측정 URL
url-test·fallback을 쓴다면 측정 URL이 실제 스트리밍 경로와 무관한 작은 객체만 보고 있지 않은지 확인하세요. 자세한 설정은 정책 그룹·지연 측정 글을 함께 보는 것이 좋습니다. YT 그룹 안에서만 노드를 바꿔 가며 같은 영상을 재생해 보면, 「회선은 정상인데 Clash 규칙만 켜면 버퍼가 길다」 같은 원인 분리가 쉬워집니다.
DNS·fake-ip·TUN과 재생 경로
DNS 응답과 프록시 출구가 다르면 TLS는 열려도 앱이 다음 단계로 진행하지 못하는 경우가 있습니다. fake-ip를 쓸 때는 DOMAIN 규칙과 리졸버가 같은 전제를 공유하는지 점검해야 합니다. nameserver·fallback·fake-ip-filter를 단계적으로 맞추려면 Meta DNS 가이드를 참고하세요. 브라우저 DoH·OS DNS·Clash DNS를 한 기기에서 뒤섞으면 우선순위가 꼬이기 쉬우니, FAQ의 연결·DNS 항목과 함께 한 갈래로 정리하는 편이 낫습니다.
TV·셋톱·모바일 앱·게임 콘솔 일부는 시스템 프록시를 무시합니다. 이때는 TUN으로 라우팅 테이블에 올리는 편이 확실한 경우가 많습니다. 다른 VPN·기업 보안 에이전트와 겹치면 충돌이 나므로, 병용 전 TUN 심화 글에서 패턴을 읽어 두세요. 증상이 특정 기기에서만 난다면 그 기기의 DNS 고정·IPv6 경로도 함께 의심합니다.
연결 로그로 출구를 맞추는 법
추측보다 로그에 찍힌 정책 적중과 목적지를 봅니다. 홈 로드 직후·재생 버튼 직후·첫 세그먼트 요청 직후에 어떤 접미사가 YT를 탔는지, 동일 세션의 다른 호스트가 DIRECT로 새는지를 나란히 적어 두면 규칙 수정이 빨라집니다. TLS 단계에서 끊기는지는 timeout·TLS 진단 글과도 연결됩니다. GUI마다 로그 가독성이 다르므로 클라이언트 선택 때 진단 화면을 기준에 넣을 만합니다.
핵심은 「전부 프록시」도 「최소 프록시」도 아니라, 재생에 필요한 이름 공간을 한눈에 덮는 중간의 명시성입니다. 규칙이 읽히면 매일 밤 노드 룰렛을 돌릴 필요가 줄어듭니다.
약관·합법망을 먼저 두는 이유
일부 지역에서는 VPN·프록시 사용이 제한되거나 계약 위반으로 이어질 수 있습니다. Premium·결제·Family 구성은 특히 약관과 결제 규정을 따릅니다. 기술적 가능성과 합법적 이용 범위는 별개이므로, 프로필을 바꾸기 전에 약관과 내부 보안 정책을 확인하는 것이 안전합니다.
맺음말: 글로벌 OTT 중에서도 YouTube는 이름 공간이 넓다
YouTube 버퍼링·재생 끊김 문제는 종종 단일 스위치가 아니라 여러 호스트의 출구 불일치에서 옵니다. Clash는 정책 그룹·도메인 분류·원격 규칙 세트·DNS 모드로 그 불일치를 드러낼 수 있고, ChatGPT·Copilot류 AI 도메인 분류만 조였던 프로필에도 스트리밍 분류 블록을 병렬로 두면 서로 간섭을 줄일 수 있습니다. OTT마다 표가 다르므로 Netflix용 nflxvideo 묶음이나 Disney+용 bamgrid 묶음을 그대로 YouTube에 붙이면 구멍이 남습니다. 같은 사고방식을 쓰되 도메인 세트는 서비스별로 다시 관측하는 것이 정답에 가깝습니다.
노드 품질은 날마다 변하지만, 어떤 이름이 어떤 정책을 탔는지가 기록 가능하면 원인 분리가 빨라집니다. 새 엔드포인트가 보이면 접미사를 보강하고, DNS와 TUN을 같은 전제로 맞추며, YT 그룹 안에서만 A/B 테스트를 하면 지역 검출과 재생 안정성 이슈도 추측이 아니라 확인으로 바뀝니다. 불투명한 「부스터」보다 규칙이 파일에 남는 쪽이 장기적으로 덜 지치는 운영입니다.
→ Clash를 무료로 다운로드해 YouTube 관련 호스트를 한 스트리밍 노드 정책으로 묶고, 버퍼가 길 때마다 규칙 룰렛 대신 로그로 원인을 줄여 보세요.