‘이 지역에서는 이용할 수 없습니다’부터 나누기

Prime Video와 브라우저·앱에 통합되는 Amazon Video 계열 증상은 한 문장 에러지만 원인 분기는 많습니다. 앱 시작 화면은 정상인데 상세 페이지에서 오류 카드만 뜨는 경우, 혹은 제목 선택 직후에만 DRM·네트워크 경고가 반복되는 경우처럼 ‘연결 자체가 아니라 경로별로 상태가 다른’ 패턴을 자주 봅니다. Clash를 두고 있으면 이럴 때도 첫 관문은 크게 세 가지입니다.

  • 노드 출구 리전과 결제 리전 불일치처럼 정책이 UI에서 차단되는 경우와, 순수히 기술 경로 문제를 구별합니다.
  • DNS가 시스템이나 브라우저 DoH·앱 내장 리졸버로 분산되어 규칙과 다른 응답을 받아 DNS 유출처럼 보이는 상태인지 확인합니다.
  • Amazon은 인증·상품 카탈로그 요청과 실제 스트림 토큰·세그먼트 호스트가 서로 다른 상표·패턴 도메인(대표적으로 aiv-로 시작하는 패턴 포함)으로 잡히는 경우가 많으므로, 분할 규칙에서 한 줄이라도 놓치면 카탈로그와 재생이 서로 다른 전략 그룹을 타게 됩니다.

이 글은 허용된 접속 조건 안에서 라우팅을 점검하는 체크리스트입니다. 지역 라이선스·계약·결제 규약은 현지법과 서비스 약관이 우선입니다. 따라서 같은 설정이라도 결과가 사용자 조건과 다르게 나올 수 있음을 명시합니다.

Netflix, Disney+, Max, YouTube 글과 실제로 무엇이 다른가

저희 스트리밍 심화 글 세트가 공통적으로 말하는 틀은 도메인으로 먼저 묶은 뒤 DNS와 노드를 같은 축에 맞춘다는 순서입니다. 다만 플랫폼마다 우선 놓아야 할 호스트 줄이 바뀌어 문서 간에 복붙 규칙만 바꾸면 새는 형태가 됩니다.

Netflix는 카탈로그 계열 호스트와 nflxvideo.net 계열 같은 세그먼트 패턴 분리 전제였고, Disney+는 bamgrid.com 브라우즈 축 설명 비중이 큽니다. Max·HBO 라인은 로그인·재생 라인이 Warner 브랜드 도메인 쪽과 맞물리고요. YouTube·googlevideo는 사용자 생성 콘텐츠와 광고·측정 경로까지 한데 얽히는 패턴이라 DNS와 출구 불일치가 더 자주 문제로 드러납니다.

반대로 Amazon Video·Prime Video 계열에서는 상점·계정 접점 호스트와 브라우징 카탈로그, 실제 재생용 세그먼트·CDN 호스트가 서로 다른 경우가 많지만 통합 회원 정책 아래 두어져 있습니다. 그래서 브라우저에서 같은 프록시로 연 amazon.co.kr처럼 국가별 상점 도메인이 원활해 보여도 플레이어마다 동일한 규칙 줄을 타지 않을 수 있으며, 재생 직전에야 로그와 네트워크 패널에 보이는 aiv-로 시작하는 패턴 포함 긴 이름이나 다른 Amazon 영상 CDN용 FQDN을 따로 DOMAIN 줄에 채워야 하는 경우가 일반적입니다.

안내: 시즌 업데이트·시험 기능에 따라 플레이어마다 CDN 엣지가 바뀌기 쉬운 편이라, 거대한 접미사 한 줄보다 로그와 네트워크 탭에서 반복 확인된 이름을 차례로 올려 두는 접근을 권합니다. 광역 .amazonaws.com 일괄 매칭은 다른 워크로드까지 끌고 올 확률이 높습니다.

규칙에 올릴 호스트 축(실측용 출발점)

아래 문자열들은 교육용 출발 목록입니다. 브라우저·네이티브 앱 각각과 본 계정 타입으로 실제 접속되는 이름을 교차 검증해야 합니다.

  • 브라우징과 계정 상태: primevideo.com, www.primevideo.com, avod*, atv*, unagi*, na.api.amazonvideo.com 등 카탈로그·헬프·설정 페이지로 들어가는 호스트 패턴 일부입니다. 지역 문자열 접미가 들어 있는 지역판 사이트로 리디렉션되면 줄을 나누어 보세요.
  • 아마존 범용 접점: 쇼핑 앱 안의 비디오 탭처럼 amazon.com, amazon.co.jp, amazon.co.kr 등 국가판 상점 접미를 동시에 쓰면 정책 그룹이 프라임 카탈로그와 같은 노드여야 카탈로그와 결제 상태가 불협조로 보이지 않습니다.
  • 재생 세그먼트·CDN 패턴: 로컬 테스트에서 자주 보이는 aiv-로 시작하는 호스트와 CloudFront 계열로 보이는 엣지, 혹은 amazonvideo.com 하위 세부 호스트—이름 길이가 길고 변동이 커서 한 번에 포괄 접미사로 묶지 말고, 실제 연결에서 관측된 FQDN부터 DOMAIN으로 추가합니다.
  • IPv6 불일치: 플레이 시작 직전에만 터지고 IPv4에서는 정상이면, 라우팅에 IPv6가 따로 새는 후보입니다.

너무 넓게 잡아 단일 선택 그룹에 몰면 일반적인 쇼핑 API까지 통째로 대역외 출구가 나와 체크아웃·배달 추적 페이지가 이상하게 느려집니다. DOMAIN 줄로 좁히고 반복 패턴으로 승격해 DOMAIN-SUFFIX를 쓴다는 순서를 유지하면 좋습니다.

전략 그룹과 rules: 축약 예시

아래 예시 프로필은 개념용입니다. 전략 그룹 이름·프록시 멤버·헬스 체크 URL은 사용자 구독에 맞춰 바꿉니다. 실제 재생 호스트 줄을 카탈로그 규칙보다 위에 둘지는 프로필·로그 패턴에 따라 달라질 수 있으니, 테스트할 때마다 매칭 로그 기준으로 조정합니다.

YAMLproxy-groups:
  - name: "Streaming-PV"
    type: url-test
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50
    proxies:
      - DIRECT
      # keep only egress proxies aligned with your catalog/play region ...

  - name: "Shopping-AMZ"
    type: select
    proxies:
      - DIRECT
      # optional: group shopping/API traffic similarly ...

rules:
  - DOMAIN-SUFFIX,primevideo.com,Streaming-PV
  # prepend DOMAIN lines for observed aiv-* / playback hosts above this block

  - MATCH,Shopping-AMZ

두 개 이상 서로 다른 전략 그룹이 출구 리전만 다르고 나머지는 같은 구독을 가리켜 보여도 세션별로 규칙 매칭은 미묘하게 갈립니다. url-test 헬스는 통과해도 영상 세그먼트 호스트만 드랍된다면 해당 호스트 줄이 헬스 체크와 같은 회선을 타는지 따로 검증해야 합니다.

DNS, fake-ip, 유출 패턴

enhanced-mode: fake-ip에서는 대부분의 호스트 이름이 규칙 단계까지 올 일이 있지만, 앱이 이미 잡아 둔 소켓을 IP 주소만으로 연다면 도메인 규칙이 건너뛰어지거나 RULE 목록 순서 때문에 기대한 줄까지 도달하지 못할 때가 있습니다. 브라우저만 정상이고 Fire TV 같은 독립 앱만 실패하면 TUN으로 경로를 한 축으로 모으는 방안을 우선 검토 목록 상단으로 올리는 편이 좋습니다.

시스템 DNS·브라우저 DoH와 앱 내부 리졸버가 다른 상위 전달자를 참조하면 카탈로그 응답과 재생 줄의 DNS가 달라 보이는 패턴입니다. 순서 변경은 하나씩 끊어 가세요. 헬스가 전부 깨져야 할 비상 순서에서는 지연·UDP·DNS 일반 진단글과 연결해서 범위를 줄일 수 있습니다.

Sniffer와 GEOIP, RULE-SET 순서

암호화된 초깃값만 보이던 연결이 늦게 도메인 식별으로 넘어가면 스트리밍 줄이 다른 정책에 먼저 걸린 뒤에야 교정된다는 패턴입니다. Mihomo 계열이라면 도메인 전환 전략이 있을 경우 Sniffer 장문 설정과 동시에 같은 로그 줄을 검토해야 합니다.

다시 말하면 Clash 규칙표는 첫 매칭 이후 줄을 무시합니다. 거대 지역 패턴 줄을 위쪽에 깔아 두었다가 그 아래 쪽에 새로 작성한 영상 줄이 있다면 새 줄은 절대 호출되지 않습니다. 규칙 분할 장문 안내서에서 다룬 위아래 순서 논리를 그대로 적용하면서, 플레이 테스트에서 새로 채워 넣은 aiv-*류 호스트 줄을 패턴 줄보다 앞쪽에 올린다고 생각하시면 되겠습니다. 외부 RULE-SET이 Amazon 태깅 줄을 포함한다면 순서 교체가 간단하게는 되지 않을 수 있습니다.

출구 노드·데이터센터 속성 선택

  1. 리전 일치 테스트: 동일 테스트 계정이라도 카탈로그 줄과 재생 세그먼트 호스트 줄에 서로 다른 대륙 노드가 붙으면 지역 불일치로 막히는 패턴처럼 보일 수 있습니다. 전략 그룹 이름이 로그에서 줄마다 어떻게 찍히는지 먼저 확인합니다.
  2. 대역 속성 차단: 일부 스트림 엣지가 데이터센터·공유 VPS 대역을 차단하면 UI는 되고 버퍼만 반복되는 식입니다. 같은 타이틀을 다른 노드 풀로 돌려 비교합니다.
  3. 이중 패스: 목록·메타 요청 줄은 정상인데 재생 시작 직후에만 다른 호스트가 추가로 뜬다면, 그 두 번째 호스트를 별도 DOMAIN 규칙으로 올리는 것이 신호입니다.
  4. 혼선과 시간대: 특정 시간대에만 패킷이 몰린 엣지 현상이라면 테스트 시간을 바꿔 재현성을 확인합니다.

주의: 출처 불명 원격 규칙 패키지에 악성 리다이렉트나 과도하게 넓은 접미 규칙이 섞일 수 있습니다. 본문에서 권장하는 호스트 줄은 사용자가 로그와 네트워크 패널로 직접 확인해 둔 순서부터 반영하는 편이 안전합니다.

웹·네이티브 앱·Fire TV 차이

브라우저는 시스템 프록시를 비교적 잘 따르지만, 일부 게임기·세트톱·Fire TV 클래스 기기는 시스템 DNS·프록시를 우회하는 경로가 있습니다. PC 카탈로그는 안정적인데 거실 세트에서만 재생 호스트 규칙이 어긋나면 라우팅 레벨 TUN이나 허브형 게이트웨이로 트래픽 축을 맞추는 방향을 검토합니다. 허브 환경의 방화벽은 Allow LAN 체크리스트와 함께 보면 좋습니다.

실측이 반복 가능한 순서

  1. 대시보드·로컬 로그에서 먼저 매칭된 규칙 이름과 전략 그룹을 확정합니다. 재생용 호스트가 예상한 줄과 다르면 카탈로그 줄과 재생 줄의 상대적 순위를 교차 바꿉니다.
  2. 시스템·브라우저·앱 DNS를 한 채널씩 끊어 가며, 카탈로그 요청과 스트림 요청 모두 같은 Clash 리졸버 경로를 타도록 맞춥니다.
  3. 특정 클라이언트에서만 추가 호스트가 보이면 그 이름만 골라 DOMAIN 줄을 새로 만들고 다른 글들과 같은 방식으로 A/B 테스트합니다.
  4. 기술 경로 문제를 배제한 뒤에도 메시지가 남으면 계정 결제 리전·앱 버전 업데이트 등 정책 쪽 가능성까지 함께 조사합니다.

마무리

2026년에도 Prime Video·Amazon Video·aiv 패턴 호스트·DNS·노드는 검색량이 많은 축입니다. 방법론은 Netflix 같은 기존 스트리밍 글과 같아도 실제 문자열 줄 묶음은 플랫폼별로 따로 두는 편이 맞습니다.

Clash는 규칙 표현력이 커 디버깅 부담도 있지만, 순서 한 줄이 전체 카탈로그를 다른 정책으로 덮는 실수부터 빠르게 걷어낼 수 있다는 장점이 있습니다.

설치와 개요는 문서·설정 요약을 참고하고, 테스트용 프로필이 준비됐으면 체감까지 비교해 → Clash를 무료로 받아 차이를 직접 확인해 보세요. 호스트 목록은 시즌·클라이언트 변경에 맞춰 덧붙이면 되고, 파일명의 연도 접미는 연간 가이드 검색에서도 구분에 도움이 됩니다.