1. 「안 열림」과 「지역 오류」가 갈라지는 이유
Netflix는 사용자에게 하나의 앱처럼 보이지만, 내부적으로는 계정·구독 상태, 카탈로그·포스터 CDN, 실제 재생 세그먼트, DRM·라이선스 교환, 간헐적으로 붙는 측정·품질 진단 호스트가 서로 다른 도메인과 엣지로 나뉩니다. 그중 일부만 직접 연결(DIRECT)로 빠지거나, 다른 노드로 새면 사용자 입장에서는 「홈은 뜨는데 재생 버튼만 회색」이나 「특정 화질에서만 끊김」처럼 증상이 짤막하게 보이기도 합니다. 지역 감지는 출구 IP뿐 아니라 DNS 응답 경로·TLS SNI·앱이 선택한 엣지 조합으로 판단하는 경우가 있어, 규칙 한 줄이 아니라 세션 전체의 일관성이 중요합니다.
프록시 사용자에게 자주 나오는 패턴은 다음과 같습니다. 첫째, 웹·앱 UI는 프록시를 타는데, 비디오 플레이어가 붙는 Open Connect 호스트만 다른 정책 그룹으로 매칭되는 경우입니다. 둘째, 시스템·브라우저 DoH가 Clash 밖에서 먼저 응답을 받아, 규칙이 기대한 출구와 실제 연결이 어긋나는 경우입니다. 셋째, fake-ip 모드에서 애플리케이션이 캐시한 주소와 스니퍼가 복원한 도메인 정보가 엇갈려 재시도 루프에 빠지는 경우입니다. 넷째, 모바일에서 시스템 VPN·앱별 DNS·셀룰러 프로필이 겹쳐 이중 해석이 생기는 경우입니다. 그래서 Netflix 이슈는 「전부 프록시」만으로 끝나기보다, 로그에 찍힌 실패 호스트를 기준으로 묶음을 다시 짓는 편이 재현에 유리합니다.
한 줄 정리
증상이 갈라지면 UI·재생·라이선스·측정 중 어디가 다른 출구를 탔는지 로그로 먼저 확정하세요. 그다음 도메인 규칙과 DNS·fake-ip를 같은 실험에 넣습니다.
2. Disney+ 글과 무엇이 다른가
Disney+ 글은 bamgrid.com·dssott.com 같은 BAMTech 축을 중심으로 묶습니다. 반면 Netflix는 Open Connect 엣지와 이미지·정적 자산 축이 nflxvideo.net·nflximg.net 등으로 넓게 퍼지는 편이라, 단순히 Disney 글의 호스트만 바꿔 붙이면 세그먼트 일부가 빠질 수 있습니다. 또한 Netflix는 브라우저·스마트 TV·게임 콘솔·셋톱 앱마다 붙는 호스트 접미가 달라, 플랫폼별 로그를 나눠 보는 것이 안전합니다.
목적은 이용 약관·지역 정책을 우회하라는 뜻이 아니라, 네트워크 경로를 좁히는 기술 체크리스트를 제공하는 것입니다. 회사망·학교망·공용 단말에서는 IT 정책과 스트리밍 정책을 먼저 확인해야 하며, 본문은 개인 학습·합법적 구독 환경에서의 트러블슈팅 전제로 서술합니다.
3. 규칙에 넣기 좋은 Netflix 관련 도메인
인프라는 시기에 따라 바뀔 수 있으므로 아래는 출발점입니다. 실패가 이어지면 Clash 로그에서 타임아웃·TLS 실패가 난 호스트를 복사해 접미 규칙으로 정리하세요. 흔히 등장하는 축으로는 서비스 웹·API에 가까운 netflix.com·netflix.net, 이미지·정적 자산의 nflximg.net, 재생·Open Connect에 연결되는 nflxvideo.net 계열, 일부 클라이언트에서 보이는 nflxext.com·nflxso.net, 품질·측정에 붙는 fast.com·nccp.netflix.com류가 거론됩니다. 긴 엣지 이름은 시간대에 따라 달라질 수 있어, 처음에는 로그에 찍힌 DOMAIN 한 줄을 넣었다가 패턴이 보이면 DOMAIN-SUFFIX로 승격하는 방식이 안전합니다.
DOMAIN-KEYWORD,netflix처럼 지나치게 넓은 키워드는 다른 서비스·추적 도메인까지 끌어올 수 있어 비추천입니다. 대신 재생 실패 직전에 붙는 호스트 묶음을 우선순위 높은 규칙 블록으로 올리고, 그 아래에 지역·직접 연결 규칙을 두는 형태가 일반적입니다. 규칙 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.
UI·카탈로그 vs 재생
포스터·설명은 뜨는데 본편만 실패하면 메타 호스트와 스트림 호스트가 갈라졌을 가능성을 의심합니다. 같은 화면에서 네트워크 탭·프록시 로그를 같이 봅니다.
지역 메시지
지역 오류가 반복되면 출구 IP뿐 아니라 DNS 응답 경로와 TLS 호스트 이름이 한 국가로 보이는지 교차 확인합니다. 계정 청구 국가와 엇갈리면 카탈로그가 달라 보일 수 있습니다.
4. DNS·fake-ip·DoH 누수를 같이 본다
Clash에서 fake-ip를 쓰면 애플리케이션은 가짜 주소로 연결을 열고, 코어가 스니퍼 등으로 도메인을 되살려 규칙을 적용합니다. 이 흐름이 깨지면 「규칙은 맞는데 실제 소켓은 다른 길로 간다」는 느낌이 납니다. 반대로 시스템이나 브라우저가 Clash 밖의 DoH로 먼저 해석하면, 규칙 전에 이미 다른 응답을 받아 출구가 흔들릴 수 있습니다. Netflix처럼 지역 판별이 민감한 서비스는 DNS가 어디서 응답하는지를 UI·캡처 도구·로그로 한 번 고정하는 것이 좋습니다.
실무에서는 다음을 번갈아 시험합니다. 첫째, Clash DNS 설정에서 enhanced-mode와 nameserver 폴백 순서가 의도와 맞는지 확인합니다. 둘째, 운영체제 네트워크 설정과 브라우저의 보안 DNS를 끄거나 Clash 쪽으로 맞춰 이중 해석을 없앱니다. 셋째, 특정 앱만 문제면 TUN 모드와 시스템 프록시 모드를 바꿔 트래픽이 실제로 코어를 통과하는지 비교합니다. Windows에서 앱이 우회하는 경우는 TUN·UWP 루프백 글의 체크리스트도 참고할 만합니다.
팁: 규칙을 늘리기 전에 DNS 응답이 한 곳으로 모이는지부터 확인하면, 불필요한 규칙 중복을 줄일 수 있습니다. 특히 Android의 「개인 DNS」와 iOS의 프로필이 겹치면 증상이 플랫폼마다 달라집니다.
5. 스니퍼와 TLS 호스트 복원
mihomo 계열에서는 sniffer로 TLS Client Hello의 SNI나 HTTP Host에서 도메인을 복원해, IP 기반 매칭이 부족한 구간을 메우는 경우가 많습니다. 스트리밍은 연결이 길고 세션이 많아, 스니퍼 설정이 과하면 CPU 부담이 늘 수 있고, 너무 좁으면 일부 흐름을 놓칠 수 있습니다. 실측에서는 Netflix 재생을 켠 직후 로그에 찍힌 스니퍼가 잡은 도메인과 rules 매칭 결과를 나란히 보는 것이 빠릅니다. HTTPS가 이상하게 직행한다면 Sniffer·SNI 로그 글의 순서로 교차 검증하세요.
QUIC(HTTP/3)이 켜진 환경에서는 일부 클라이언트가 다른 경로를 탈 수 있어, 브라우저에서 HTTP/3를 잠시 끄고 비교 실험을 하기도 합니다. 다만 TV·콘솔 앱은 설정이 분리되어 있으므로, 동일 증상이 웹과 앱에서 재현되는지부터 나누는 것이 좋습니다.
6. mihomo rules 스니펫 예시
전용 정책 그룹 이름을 예시로 📺 Netflix라고 하면, rules 상단 쪽(넓은 MATCH·지역 규칙보다 앞)에 스트리밍 관련 줄을 두는 형태가 일반적입니다. 그룹명·노드명은 구독 프로필에 맞게 바꿉니다. 아래는 교육용 예시이며, 실제 서비스는 호스트가 바뀔 수 있으니 로그 기반으로 보강해야 합니다.
rules: # Netflix — place above broad GEOIP / MATCH - DOMAIN-SUFFIX,netflix.com,📺 Netflix - DOMAIN-SUFFIX,netflix.net,📺 Netflix - DOMAIN-SUFFIX,nflximg.net,📺 Netflix - DOMAIN-SUFFIX,nflxvideo.net,📺 Netflix - DOMAIN-SUFFIX,nflxext.com,📺 Netflix - DOMAIN-SUFFIX,nflxso.net,📺 Netflix - DOMAIN-SUFFIX,fast.com,📺 Netflix # Add CLIENT-NAME / DOMAIN hits from live playback logs # ... LAN, CN, then MATCH - GEOIP,PRIVATE,DIRECT - MATCH,🔰 Proxy
구독이 갱신될 때 규칙이 덮어쓰이지 않게 하려면, 구독 가져오기에서 프로필 머지 순서를 확인하세요. 노드가 자주 바뀌는 url-test 그룹에 스트리밍을 묶었다면, 재생 중 전환으로 세션이 끊기지 않는지도 함께 봅니다. 지역이 흔들리면 한동안 고정 노드로 재생만 따로 실험해 보는 것도 원인 분리에 도움이 됩니다.
7. 실측 점검 순서
권장 순서는 다음과 같습니다. 먼저 Clash를 규칙 모드로 두고 Netflix에서 짧은 예고편과 본편을 각각 재생해 봅니다. 로그에서 두 경우 매칭된 규칙 줄과 아웃바운드 이름이 같은지 확인합니다. 다음으로 DNS가 Clash 경로로만 해석되는지 점검하고, fake-ip 사용 시 스니퍼가 기대한 도메인을 복원하는지 봅니다. 세 번째로 동일 노드를 고정한 채 IP 지역 확인 사이트와 스트리밍 앱의 지역 안내를 비교하되, 이는 참고용이며 서비스 측 판별 로직과 1:1로 같지 않을 수 있습니다. 네 번째로 fast.com 같은 측정 트래픽이 재생 세션과 다른 출구를 타면 품질·적응 비트레이트에 간섭이 생길 수 있으니, 필요하면 같은 정책 그룹에 함께 묶습니다.
로그에서 볼 것
호스트·스니퍼 복원 도메인·정책 그룹·최종 아웃바운드가 한 흐름으로 이어지는지 확인합니다. 한 세그먼트만 다른 그룹으로 새면 버퍼링·코덱 협상 실패로 이어질 수 있습니다.
모바일·TV 앱
앱은 시스템 VPN·개별 Wi-Fi 프록시·셀룰러 DNS를 다르게 씁니다. 동일 계정으로 웹과 앱을 나눠 재현해, 어느 쪽에서만 깨지는지 먼저 좁히세요.
8. 약관·정책·마무리
Netflix는 지역·콘텐츠 라이선스·결제 수단 정책이 복잡합니다. 본문은 기술적 경로 정리에만 초점을 맞추었으며, 이용 가능 여부·계정 상태는 각 지역 약관과 고객 지원 안내를 따릅니다. 공용 회선에서는 스트리밍이 금지되거나 로깅 정책이 있을 수 있으니, 사용 환경의 규정을 먼저 확인해야 합니다.
정리하면, 2026년에도 흔한 Netflix 이슈는 ① 로그로 실패 호스트 확정 → ② Open Connect·정적 자산 축을 넓은 MATCH보다 위에 배치 → ③ DNS·DoH·fake-ip 누수 제거 → ④ 스니퍼와 TLS 복원 확인 → ⑤ 노드 전환·이중 경로 교차 검증 순서로 좁히는 것이 재현에 유리합니다. Disney+의 BAMTech 튜닝이나 AI API의 QUIC 이슈와 달리, 여기서는 nflxvideo·nflximg 계열과 UI 호스트의 정렬이 같은 표 위에 올라옵니다.
→ Clash를 무료로 내려받아 최신 클라이언트에서 규칙·DNS·로그를 한 흐름으로 점검하고, Netflix 재생·인증·CDN 호스트를 같은 실측 루틴에 넣어 보세요. 다른 도구에 비해 규칙·프로필 생태계가 넓고, 스트리밍용 정책 그룹을 고정하기 쉬운 경우가 많습니다.
관련 읽기 · 같은 주제
주제 관련도가 높은 읽을거리 — 같은 카테고리의 Clash 실전 가이드.
Disney+가 안 열리거나 예고편만 보일 때: Clash로 스트리밍 도메인·DNS·Fake-IP를 맞추는 실측 (2026)
Disney+ 본편 재생·지역 안내·무한 로딩이 날 때 재생·인증·CDN 호스트를 mihomo 규칙으로 묶고, DNS·fake-ip·DoH 누수·스니퍼 복원을 Steam·AI 글과 구분해 한 루틴으로 점검하는 순서를 정리했습니다.
자세히 보기유튜브가 자꾸 버퍼링되거나 홈이 안 열릴 때: Clash(mihomo)로 Google·영상 CDN 도메인을 분기하는 실측 (2026)
홈·인증·세그먼트·썸네일이 googlevideo·ytimg·googleapis 등으로 갈릴 때 mihomo 규칙으로 묶고, DNS·fake-ip·DoH·QUIC 대조 실험을 Netflix·Disney+ 지역 감지 글과 구분해 재생 링크를 좁히는 순서를 정리했습니다.
자세히 보기Clash는 켰는데 브라우저만 직접 연결? Windows에서 보안 DNS(DoH) 끄고 시스템 프록시 맞추기 (2026)
Clash·시스템 프록시는 켰는데 Chrome·Edge만 국선·이상한 DNS처럼 보일 때, Windows 10/11·브라우저의 보안 DNS(DoH)를 끄고 mihomo의 fake-ip·로컬 DNS 흐름과 충돌을 푸는 절차입니다. Verge Rev 시스템 프록시·TUN·구독 TLS 글과…
자세히 보기