Prime Video가 안 열리거나 지역 오류가 날 때: Amazon·영상 CDN을 Clash(mihomo)로 분기·DNS를 맞추는 실측 (2026)

1. 「안 열림」과 「지역 오류」를 나누는 이유

Prime Video는 브랜드만 보면 하나의 앱이지만, 실제 트래픽은 primevideo.com 같은 서비스 표면, amazon.com 및 각국 amazon.*에 걸친 계정·결제·세션 쿠키, 재생 협상용 API, 세그먼트가 내려오는 CDN 엣지로 층을 이룹니다. 일부만 직접 연결로 새거나 다른 노드로 흩어지면 사용자에게는 「홈 포스터는 보이는데 재생 버튼만 회색」「첫 광고까지는 되고 본편만 에러」처럼 증상이 잘게 보입니다. 지역 감지는 출구 IP만이 아니라 DNS가 어느 PoP를 가리키는지, TLS SNI가 무엇으로 보이는지, 앱이 붙은 라이선스 엔드포인트 조합까지 포함되는 경우가 많아 규칙 한 줄로 끝내기 어렵습니다.

프록시 환경에서 자주 보는 패턴은 다음과 같습니다. 첫째, 웹 UI는 프록시를 타는데 재생 호스트만 다른 정책 그룹에 매칭되는 경우입니다. 둘째, 브라우저·OS의 DoH가 Clash 밖에서 먼저 응답해, 규칙이 기대한 출구와 실제 연결이 어긋나는 경우입니다. 셋째, fake-ip 모드에서 애플리케이션이 캐시한 주소와 스니퍼가 복원한 도메인이 엇갈려 재시도 루프에 빠지는 경우입니다. 넷째, TV·콘솔·Fire 스틱처럼 시스템 프록시를 무시하는 클라이언트가 섞이면 PC 웹과 증상만 달라지는 경우입니다. 따라서 Prime Video 이슈도 「전부 해외 노드」 한 방보다 로그에 찍힌 실패 호스트를 기준으로 묶음을 다시 짓는 편이 재현에 유리합니다.

2. Netflix·Disney+ 글과 무엇이 다른가

같은 블로그의 Netflix 글은 Open Connect(nflxvideo.net 등) 축을 중심으로 묶고, Disney+ 글은 BAMTech(bamgrid.com 등) 축을 중심으로 묶습니다. Prime Video는 상위가 Amazon 이커머스 인프라와 세션을 공유하는 부분이 커서, 단순히 Netflix 규칙만 복사해 호스트 이름만 바꾸면 쇼핑·AWS 일반 API까지 같은 그룹으로 끌려와 부작용이 생길 수 있습니다. 반대로 재생에 실제로 필요한 호스트만 빠지면 DRM 협상이 실패합니다. 그래서 이 글에서는 primevideo·atv·aiv·미디어 CDN 같은 영상 축과, 정말 필요할 때만 좁혀 쓰는 cloudfront.net 하위 호스트를 분리해 서술합니다. AWS CloudFront를 넓게 다룬 글이 필요하면 Notion 동기화·CloudFront 편의 관점도 교차 참고할 수 있습니다.

목적은 이용 약관·지역 정책을 우회하라는 뜻이 아니라, 네트워크 경로를 좁히는 기술 체크리스트를 제공하는 것입니다. 회사망·학교망에서는 스트리밍 자체가 금지되거나 로깅 정책이 있을 수 있으니, 환경 규정을 먼저 확인해야 하며 본문은 개인 학습·합법적 구독 전제로 작성했습니다.

3. 규칙에 넣기 좋은 Prime Video·Amazon 축

인프라는 분기마다 바뀔 수 있으므로 아래는 출발점입니다. 재생 실패 직후 Clash 로그에서 타임아웃·TLS 오류가 난 호스트를 복사해 접미 규칙으로 보강하세요. 자주 거론되는 축으로는 서비스 표면의 primevideo.com, 계정·세션과 맞물리는 amazon.com 및 지역 TLD의 amazon.co.jp·amazon.de 등, 재생 API로 알려진 atv-ps.amazon.com류, 과거부터 스트리밍 논의에 등장하는 aiv-delivery.net·media-amazon.com 계열이 있습니다. 클라이언트마다 접미가 달라 플랫폼별 로그를 나누는 것이 안전합니다.

DOMAIN-KEYWORD,amazon처럼 지나치게 넓은 키워드는 상거래·광고·추적까지 한꺼번에 끌어올 수 있어 비추천입니다. 대신 로그에서 확인된 DOMAIN 한 줄을 먼저 넣고, 패턴이 보이면 DOMAIN-SUFFIX로 승격합니다. 규칙 우선순위 개념은 고급 라우팅 가이드와 함께 보면 이해가 빨라집니다.

4. CloudFront·광역 DOMAIN-SUFFIX 주의

Amazon 영상 트래픽에는 cloudfront.net 아래의 긴 호스트 이름이 등장하는 경우가 많습니다. 그러나 CloudFront 전역 접미사 하나를 통째로 특정 프록시 그룹에 넣으면 Prime Video와 무관한 다른 서비스까지 같은 노드로 나가 속도·차단 리스크가 커질 수 있습니다. 실무에서는 재생 중 로그에 찍힌 완전 수준 도메인(FQDN)을 규칙에 추가하는 방식이 안전합니다. 여러 FQDN이 같은 패턴을 공유하면 그때 소규모 접미 그룹으로 묶습니다.

반대로 너무 쪼개면 라이선스 협상 중 한 호스트만 빠져 전체 재생이 깨집니다. 그래서 「처음에는 로그 기반으로 넓히되, 광역 접미사는 최후 수단」이라는 순서를 권합니다. IPv6 이중 스택에서 출구만 어긋나는 경우는 TUN·IPv6·DNS 누수 글과 함께 보는 것이 좋습니다.

5. DNS·fake-ip·DoH 누수를 같이 본다

Clash에서 fake-ip를 쓰면 애플리케이션은 가짜 주소로 소켓을 열고, 코어가 스니퍼 등으로 도메인을 되살려 규칙을 적용합니다. 이 흐름이 깨지면 「YAML 규칙은 맞는데 실제 연결은 다른 길」이라는 느낌이 납니다. 반대로 OS나 브라우저가 Clash 바깥 DoH로 먼저 해석하면 규칙 적용 전에 다른 응답을 받아 출구가 흔들립니다. Prime Video처럼 CDN 엣지 선택이 민감한 서비스는 DNS가 어디서 응답하는지를 한 번 고정하는 것이 좋습니다.

실무에서는 다음을 번갈아 시험합니다. 첫째, Meta 코어 DNS 설정에서 enhanced-mode와 nameserver 폴백 순서가 의도와 맞는지 확인합니다. 둘째, 운영체제·브라우저 보안 DNS를 끄거나 Clash 쪽으로 맞춰 이중 해석을 없앱니다. enhanced-mode 선택지 자체가 헷갈리면 fake-ip와 redir-host 비교 글의 대조 표를 먼저 보세요. 셋째, 특정 앱만 문제면 TUN 모드와 시스템 프록시 모드를 바꿔 트래픽이 실제로 코어를 통과하는지 비교합니다.

6. 스니퍼와 TLS 호스트 복원

mihomo 계열에서는 sniffer로 TLS Client Hello의 SNI나 HTTP Host에서 도메인을 복원해, IP 기반 매칭이 부족한 구간을 메웁니다. 스트리밍은 세션이 길고 연결이 많아 스니퍼 범위가 넓으면 CPU 부담이 늘고, 너무 좁으면 일부 흐름을 놓칩니다. 실측에서는 재생을 시작한 직후 로그에 찍힌 스니퍼가 잡은 도메인과 rules 매칭 결과를 나란히 보는 것이 빠릅니다. HTTPS가 이상하게 직행한다면 Sniffer·SNI 로그 글의 순서로 교차 검증하세요.

QUIC(HTTP/3)이 켜진 브라우저에서는 경로가 달라 보일 수 있어, 비교 실험 때만 HTTP/3를 끄고 재측정하기도 합니다. TV·게임 콘솔 앱은 설정 분리가 어려우므로, 동일 증상이 웹과 네이티브 앱에서 재현되는지부터 나눕니다.

7. mihomo rules 스니펫 예시

전용 정책 그룹 이름을 예시로 📺 Prime Video라고 하면, rules 상단 쪽(넓은 MATCH·GEOIP보다 앞)에 스트리밍 관련 줄을 두는 형태가 일반적입니다. 그룹명·노드명은 구독 프로필에 맞게 바꿉니다. 아래는 교육용 예시이며, 실제 호스트는 시기에 따라 바뀌므로 재생 로그로 반드시 보강해야 합니다. cloudfront.net 한 줄은 영향 범위가 넓어 주석으로만 남겨 두었습니다.

rules:
  # Prime Video / Amazon Video — place above broad GEOIP / MATCH
  - DOMAIN-SUFFIX,primevideo.com,📺 Prime Video
  - DOMAIN-SUFFIX,amazonvideo.com,📺 Prime Video
  - DOMAIN-SUFFIX,media-amazon.com,📺 Prime Video
  - DOMAIN-SUFFIX,aiv-delivery.net,📺 Prime Video
  - DOMAIN,atv-ps.amazon.com,📺 Prime Video
  # Optional: region storefront used by your account (examples)
  - DOMAIN-SUFFIX,amazon.co.jp,📺 Prime Video
  - DOMAIN-SUFFIX,amazon.com,📺 Prime Video
  # Avoid blanket cloudfront.net unless logs justify each hostname

  # ... LAN, CN, then MATCH
  - GEOIP,PRIVATE,DIRECT
  - MATCH,🔰 Proxy

구독 갱신 때 규칙이 덮어쓰이지 않게 하려면 구독 가져오기에서 프로필 머지 순서를 확인하세요. url-test 그룹에 스트리밍을 묶었다면 재생 중 노드 전환으로 세션이 끊기지 않는지도 봅니다. 지역 메시지가 반복되면 한동안 고정 노드로 재생만 분리 실험해 원인을 나눕니다.

8. 실측 점검 순서

권장 순서는 다음과 같습니다. 먼저 Clash를 규칙 모드로 두고 Prime Video에서 짧은 예고편과 본편을 각각 재생합니다. 로그에서 두 경우 매칭된 규칙 줄과 아웃바운드 이름이 같은지 확인합니다. 다음으로 DNS가 Clash 경로로만 해석되는지 점검하고, fake-ip 사용 시 스니퍼가 기대한 도메인을 복원하는지 봅니다. 세 번째로 동일 노드를 고정한 채 지역 확인 사이트와 앱 안내를 비교하되, 서비스 측 판별과 1:1로 같지 않을 수 있다는 점을 기억합니다. 네 번째로 쇼핑 결제·AWS 콘솔까지 같은 그룹에 묶였는지 살펴, 필요하면 Prime 전용 그룹과 분리합니다.

9. 약관·정책·마무리

Prime Video는 지역·라이선스·결제 정책이 복잡합니다. 본문은 기술적 경로 정리에만 초점을 맞추었으며, 시청 가능 여부·계정 상태는 각 지역 안내와 고객 지원 채널을 따릅니다. 공용 회선에서는 스트리밍이 금지되거나 트래픽이 기록될 수 있으니 규정을 먼저 확인해야 합니다.

정리하면, 2026년에도 흔한 Prime Video 이슈는 ① 로그로 실패 호스트 확정 → ② primevideo·미디어 CDN 축을 넓은 MATCH보다 위에 배치 → ③ CloudFront는 FQDN 중심으로만 확장 → ④ DNS·DoH·fake-ip 누수 제거 → ⑤ 스니퍼와 TLS 복원 확인 → ⑥ 노드 전환·플랫폼 교차 검증 순서로 좁히는 것이 재현에 유리합니다. Netflix의 Open Connect 튜닝이나 Disney+의 BAMTech 튜닝과 달리, 여기서는 Amazon 계열 세션과 CDN 엣지의 정렬이 같은 표 위에 올라옵니다.

→ Clash를 무료로 내려받아 최신 클라이언트에서 규칙·DNS·로그를 한 흐름으로 점검하고, Prime Video 재생·Amazon 로그인·CDN 호스트를 같은 실측 루틴에 넣어 보세요. 규칙·프로필 생태계가 넓어 스트리밍 전용 정책 그룹을 고정하기 쉽고, 장기적으로 다른 OTT 가이드와도 같은 패턴으로 확장할 수 있습니다.