“프록시 켰는데” Netflix만 이상한 증상들

신작이 올라왔다는 소식을 듣고 앱을 열었는데 카탈로그가 평소와 다른 국가로 보이거나, 검색은 되는데 재생 버튼 직전에 검은 화면·오류 코드로 끊기는 경험은 흔합니다. 브라우저나 다른 사이트는 빠른데 OTT만 유독 그럴 때, 사용자는 보통 “노드가 느려서”라고 단정하기 쉽지만 실제로는 트래픽이 기대한 출구로 나가지 않았거나, 나갔더라도 DNS·TLS·지역 판별 API가 서로 다른 경로를 본 경우가 많습니다.

Clash·mihomo 계열은 rule 모드에서 도메인·IP·프로세스 단위로 경로를 나눌 수 있어, 일상 트래픽은 직접 연결을 유지하면서 스트리밍 관련 호스트만 특정 프록시 그룹으로 보내는 구성이 가능합니다. 이 글의 초점은 “Clash가 무엇인가”가 아니라, 지역 표시가 어긋나는 장면에서 규칙·DNS·노드를 어떤 순서로 맞추면 안정적인지입니다. DNS를 처음부터 끝까지 설명하는 범용 가이드는 YAML 가이드의 DNS·Fake-IP 절에 두고, 여기서는 스트리밍 분기와만 맞닿는 부분을 짚습니다.

왜 “연결됐다”고 느껴져도 지역이 틀릴까

OTT 서비스는 단순히 “지금 세션의 공인 IP”만 보지 않습니다. 앱·웹뷰·CDN·라이선스 검증 서버로 향하는 요청이 여러 조각으로 나뉘고, 그중 일부가 직접 연결로 새거나 다른 노드로 나가면 판별 결과가 엇갈립니다. 예를 들어 메인 페이지는 프록시 출구를 따라가는데, 재생에 필요한 서브도메인만 시스템 DNS로 해석되어 로컬 ISP 경로를 탄다면, 화면에는 “한국 카탈로그”가 보이는데 재생 단계에서만 막히는 식의 불일치가 생길 수 있습니다.

또 한 가지는 규칙 순서입니다. Clash의 rules는 위에서 아래로 평가되며 처음 맞은 한 줄이 최종 결정입니다. “전체 해외 트래픽”을 아래에 두고, 그 위에 더 넓은 조건이 DIRECT나 다른 그룹을 가리키고 있으면, Netflix 관련 도메인이 의도와 다르게 처리됩니다. GUI에서 구독 규칙 세트를 켰다면, 커스텀 스트리밍 규칙이 그보다 위에 오는지 반드시 확인해야 합니다.

팁

증상이 “느리다”보다 “지역이 하루아침에 바뀌었다”에 가깝다면, 노드 풀 변경·공항 정책 변경보다 규칙 세트 업데이트나 로컬 예외 규칙이 바뀌었는지부터 의심해 보세요.

스트리밍만 분리하는 규칙 설계

실무에서는 proxy-groups에 스트리밍 전용 그룹을 하나 두고, 이름을 PROXY_MEDIA처럼 고정해 두는 패턴이 많습니다. 멤버는 “지연 최저”가 아니라 해당 서비스에 맞는 출구를 넣습니다. select로 수동 고정해 두면 신작 오픈 날에 자동 전환이 덜해져 안정적이고, url-test를 쓰더라도 측정 URL을 일반 웹사이트가 아니라 실제 사용 중인 OTT가 잘 열리는지에 맞출 필요가 있습니다.

rules에서는 공식·커뮤니티 RULE-SET을 쓰거나, 최소한으로 DOMAIN-SUFFIX·DOMAIN-KEYWORD로 재생에 자주 쓰이는 호스트를 지정합니다. 중요한 것은 스트리밍 관련 줄이 국내 직결·기본 프록시보다 위에 있어야 한다는 점입니다. Netflix뿐 아니라 동일 앱 안의 이미지·분석·DRM 관련 호스트가 따로 도메인을 쓰는 경우가 있어, 한 줄만 넣고 끝내기보다 검증된 규칙 세트를 쓰는 편이 재발을 줄입니다.

# Conceptual excerpt — adapt names to your profile
proxy-groups:
  - name: PROXY_MEDIA
    type: select
    proxies:
      - NODE_US_1
      - NODE_US_2
      - DIRECT

rules:
  - RULE-SET,streaming_media,PROXY_MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY_DEFAULT

위는 개념 예시이며, 실제 프로필에서는 사용 중인 rule-provider 이름·경로·정책에 맞게 바꿔야 합니다. 핵심은 “스트리밍 세트 → 미디어 그룹”이 넓은 GEOIP나 MATCH보다 먼저 나온다는 구조입니다.

노드 선택: 빠른 노드와 ‘맞는’ 노드는 다르다

범용 인터넷 속도가 빠른 릴레이가 OTT 재생에도 최적인 것은 아닙니다. 일부 데이터센터 출구는 스트리밍 사업자 측에서 데이터센터 IP 대역으로 분류되어 접속은 되지만 화질·지역 판별이 제한되는 경우가 있습니다. 반대로 지연이 조금 더 있어도 가정용 회선에 가까운 분류를 받는 출구는 카탈로그 일치율이 높을 수 있습니다.

그래서 미디어 그룹에는 “메인 업무용 url-test 그룹”을 그대로 넣기보다, 구독 안에서 스트리밍용으로 표시된 서버만 모아 두거나, 별도 프로바이더를 붙이는 방식이 안전합니다. 구독 URL을 정리하고 노드 이름을 필터링하는 절차는 구독 변환·필터링 가이드와 함께 보면 프로필 전체와 충돌이 적습니다.

주의

서비스 이용약관·저작권·지역 라이선스를 위반하는 용도의 회피를 돕는 내용은 다루지 않습니다. 이 글은 합법적으로 이용 권한이 있는 계정에서 기술적 경로 불일치로 인한 표시·재생 문제를 줄이는 설정에 한합니다.

DNS·해석: 스트리밍 분기와 맞물리는 지점

DNS “유출”을 길게 설명하는 대신, 스트리밍 장면에서 필요한 인식만 정리하면 다음과 같습니다. 앱이 시스템 리졸버로 먼저 물어보고, 그 응답이 로컬망 기준이면 브라우저 확장으로 켠 프록시와 서로 다른 IP 계열을 보게 될 수 있습니다. Clash에서 enhanced-mode: fake-ip를 쓰면 로컬 앱이 받는 응답과 실제 프록시 터널 안의 질의를 분리하기 쉬워지지만, LAN·캐스트·특정 OTT는 fake-ip-filter 예외가 필요할 수 있습니다.

TUN 모드를 켜면 시스템 트래픽이 코어로 모이기 쉬워 이런 불일치가 줄어드는 경우가 많습니다. 반대로 브라우저만 확장 프록시를 쓰고 시스템은 직접 연결이면, 앱과 웹이 서로 다른 경로를 탈 수 있어 “한쪽만 이상하다”는 증상이 잘 납니다. 어떤 모드를 쓰든 같은 프로필·같은 규칙 세트를 바라보는지부터 맞추는 것이 좋습니다.

Fake-IP·폴백 DNS·nameserver 구성의 전체 그림은 YAML 심층 가이드에서 단계별로 다룹니다. 이 글에서는 “스트리밍만 틀어진다”면 규칙을 고치기 전에 DNS 모드와 예외 목록을 한 번 점검해 보라는 정도만 기억하면 충분합니다.

앱·브라우저·IPv6까지: 흔한 빈틈

스마트 TV·콘솔·타블렛 앱은 OS 수준 프록시를 무시하고 직접 DNS·직접 연결을 쓰는 경우가 있습니다. 같은 Wi-Fi에 있는 PC에서는 Clash가 잘 돌아가도, TV 앱만 다른 지역으로 보이면 “가정망의 다른 기기” 쪽을 의심해야 합니다. 가능하면 OTT를 시험하는 기기와 Clash를 돌리는 기기를 동일한 터널 정책 아래에 두고 비교하세요.

IPv6가 켜져 있으면 AAAA 응답을 따라 트래픽이 IPv6로만 나가며, 프록시 규칙이 기대와 다르게 적용되는 사례가 있습니다. 일시적으로 IPv6를 끄고 재현 여부를 보거나, 코어에서 IPv6 관련 정책을 프로필에 맞게 정리하는 방법이 있습니다. 환경마다 다르므로 “증상 재현 → 한 가지 변수만 바꾸기”로 좁히는 것이 안전합니다.

점검 순서 체크리스트

설정을 크게 뒤집기 전에 아래 순서를 권합니다.

  1. 모드가 rule인지, 지금 보고 있는 프로필이 실제로 로드됐는지 확인한다.
  2. rules에서 스트리밍 관련 줄이 DIRECT·넓은 MATCH보다 위에 있는지 본다.
  3. PROXY_MEDIA 등 미디어 그룹이 가리키는 노드가 의도한 출구인지, 자동 전환 그룹이 너무 공격적이지 않은지 본다.
  4. DNS가 Fake-IP인지, 스트리밍 도메인이 fake-ip-filter에 필요한 예외를 빠뜨리지 않았는지 본다.
  5. TUN/시스템 프록시/브라우저 확장 중 무엇을 쓰는지 통일하고, IPv6·다른 VPN과의 중복을 제거한다.
  6. 한 기기·한 앱에서만 재현되는지, 가정망의 다른 단말까지 포함해 범위를 정한다.

이 순서는 새 드라마가 올라온 날 급하게 노드를 바꾸기보다, 규칙과 경로를 먼저 고정해 두면 이후에도 같은 유형의 문제를 빨리 닫을 수 있습니다.

정리

Netflix를 비롯한 OTT에서 “프록시는 켜졌는데 지역만 이상하다”는 증상은, 단일 스위치가 아니라 규칙 순서·전용 프록시 그룹·DNS 해석·실제 출구 노드가 한 줄로 이어졌을 때 가장 잘 풀립니다. 일반 웹과 스트리밍을 같은 자동 선택 그룹에 묶어 두면 편하지만, 판별 방식이 다른 트래픽은 분리해 두는 편이 장기적으로 안정적입니다.

Clash·mihomo는 YAML 한 장으로 이런 분기를 명시적으로 유지할 수 있어, 문제가 생겼을 때도 원인 후보를 빠르게 좁힐 수 있습니다. 최신 클라이언트 빌드와 호환되는 코어 조합은 다운로드 페이지에서 확인할 수 있습니다. → Clash를 무료로 내려받아 프로필과 규칙을 정리한 뒤, 스트리밍 전용 그룹부터 차근차근 맞춰 보시기 바랍니다.