なぜ Max だけ Clash の「層」が原因になりやすいのか

Max（旧 HBO Max。Warner Bros. Discovery 傘下）は、ストリーミング向けの長尺配信のなかでも、華語圏の掲示板や SNS で「地域が合わない」「この地域では利用できない」系の案内を見る頻度が高いサービスです。Netflix や Disney+ と並びストリーミングの比較で語られやすい一方、実装上はmax.com 系の表側と、認証・カタログ API、サムネイル、実際の映像 CDN が別ホストに分かれ、どこか一つが分流ルールの外に落ちるだけで、画面上は「地区」まわりのメッセージに見える、という切り分けがよく出ます。

本稿は、当ブログ既稿の Netflix 向けのカタログ／画質の実測 や、Disney+ 向けのドメイン束と専用グループ と重複する前提説明を省き、Max／HBO 系のドメイン設計、レガシー hbo.com の取り扱い、DNS リークの見え方、Sniffer 絡みの挙動までを一続きの手順にまとめます。各サービスごとに DOMAIN-SUFFIX の束は噛み合いません。まとめ買い用の「万能ルール」より、ログに出たホスト名を足していく方が、長期運用では安全です。

ステップ 1：HBO Max から Max へ——レガシー ドメインをどう扱うか

ブランド改称後も、ログイン導線・アプリ内ディープリンク・メール内 URL に hbo.com 系が残る期間は普通にあります。ルール集が新しいドメインだけを列挙していると、認証の一段だけ意図せず DIRECT や別グループに落ち、トークン取得と再生 CDN の出口が食い違います。接続履歴（またはログ）に hbo が混ざっていても、最初は不具合ではなく想定内の名残行のことがあります。

方針としては、（1）まず max.com およびサブドメインを DOMAIN-SUFFIX で一つのプロキシグループに寄せ、（2）hbo.com も同系として同グループに含める、（3）将来レガシーが消えたらルールを削る、の三段が扱いやすいです。DOMAIN-KEYWORD の乱用は、他サービスを巻き込みやすいので、ログで実際に出たサフィックスに寄せるのが無難です。分流の優先度の考え方は ルール分岐の詳解 の「細かい DOMAIN 系を上、GEOIP や MATCH を下」という話と同じ土台に乗ります。

ステップ 2：Web／アプリ／テレビで「通る層」が違う

ブラウザ版と専用アプリ、スマート TV やゲーム機では、システムプロキシを見るか、TUN による仮想 NIC でホスト丸ごと取り込むか、が分かれます。ブラウザだけ HTTP／SOCKS に乗り、アプリが直結のままだと、ログインは通るが再生が地域エラー、という層のズレが起きがちです。家電系は TUN モード の解説にあった「どのプロセスがプロキシを見るか」がそのまま当たります。ルーター直下に透過プロキシを置いている場合は、PC 向けの記事よりも、ゲートウェイ側の DNS 先が先に来る点に注意してください。

ステップ 3：ストリーミング向けドメインを「束」で切り出す

配信本線はワンホストでは完結しません。画像、エラー文言用の API、AB テスト、実際の映像バイト、DRM 周辺、といった層に跨ります。典型的には、サービス本丸の DOMAIN／DOMAIN-SUFFIX に加え、証明書が別になる CDN 名がログに出ます。分流ルールで一部だけ違う地域のノードに流れると、地域判定の前提が崩れます。ここは Max 固有の羅列をコピペで固定するのではなく、ご自身のログに現れた FQDNを足す形が、改版にも強いです。

Sniffer と「見え方」のズレ

mihomo 系で sniff を有効にしていると、Fake-IP フェーズのホスト名と、実体の SNI／HTTP Host が揺れることがあります。ストリーミング専用の DOMAIN が効いているつもりが、解決前の通過ルールで意図しないグループに入る、といった相談は、当サイトの Sniffer とストリーミングの整理 に近いです。疑わしければ、一時的に手動 select で地域を固定し、override-destination や ルール優先度の順序を一つずつ確かめます。

ステップ 4：専用プロキシグループと url-test の罠

汎用の PROXY 一括に載せたまま url-test や fallback 任せにすると、測定用 URL の応答は良いが、実映像の出口だけ別大陸、という揺れが出ます。長尺は帯域と安定性が効くので、ストリーミング専用のプロキシグループを切り、まず select で想定リージョンに固定するのが扱いやすいです。遅延テスト数値は参考に留め、数分の連続再生で観察するのは、Netflix 稿 でも同じ趣旨を述べています。

ステップ 5：DNS リークと Fake-IP／DoH の整合

DNS クエリの一部が OS の DoH、キャリアの DNS、Private DNS、あるいはルータ直に抜けていると、ルール評価用の名前解決と実接続の IP が食い違います。これが画面上の「地域」メッセージのように見える典型です。dns.enhanced-mode が fake-ip の場合は、特に nameserver／fallback の到達経路、IPv6（AAAA）の片道不通、システム DNS との二重化を点検します。DoH の URL 自身がプロキシ必須ドメインだと、初回だけ解決が詰まるパターンも忘れがちです。

接続元がモバイルの場合は、Android 向け接続切り分け と併せ、Wi-Fi 固定で再現するのも有効です。購読の鮮度が古いと、そもそも 分流ルールのカバー外ドメインが多いまま、という下敷きもあり得ます。手順の共通点は サブスクリプション URL 追加 に集約しています。

ステップ 6：ノード出口とカタログの整合

同じ国名表示でも、データセンター由来の IP と、回線事業者らしい出口では、事業者側のリスク判定が変わる場合があります。ここは各サービスの利用条件に従う前提で、技術的には期待するカタログに対応しそうな出口を手動で選び、セッション（Cookie／アプリ内セッションデータ）を切り替えた直後は一度ログアウトする、といった運用が安定しやすいです。Disney+ 稿の「長尺特化の設計思想」、Netflix 稿の「カタログと画質の層」はそのまま参考になり、本稿の差分は Max／HBO 名義の併存と、Warner 系配下ドメインの取り扱いに置かれます。

ステップ 7：TUN、ファイアウォール、テレビ

PC ブラウザ以外を同一ネットに乗せるなら、TUN か、ゲートウェイ透過、のどちらかに寄せ切るのが分かりやすいです。企業系エンドポイントが仮想 NIC を止めたり、別 VPN が競合したりしていると、Web だけ通る症状も出ます。ローカル宛の fake-ip 例外や、redir／tun の取り違いは、TUN 記事 の層分け図式と併せて確認してください。

短いチェックリスト

1. 視聴クライアント層（ブラウザ／アプリ／TV）が、同一のプロキシスタックを参照しているか。
2. max.com 系と、必要なら hbo.com 名残の両方を、意図した プロキシグループに載せ切れているか（漏れと過剰の両方）。
3. DNS リーク：Fake-IP、DoH、システム／キャリア、IPv6 の片道、Private DNS。
4. Sniffer・override-destination ・ルール順序が、ストリーミングの SNI 解釈を狂わせていないか。
5. ノード出口の地域がカタログと揃いそうか、セッションを切るべきタイミングか。

ドキュメントと入手

プロファイル全般の書式や高度な項目は、当サイトの チュートリアル・ドキュメント を参照してください。クライアントの実行ファイルは、表記揺れの少ない導線として、各 OS の ダウンロードページを第一選択にするのがおすすめです。

まとめ

Max（HBO Max からの改称を含む）の地域まわりの表示は、単一の「正解ノード」より、Clash における DOMAIN-SUFFIX の束、専用プロキシグループ、DNS の抜け道、Sniffer やルール優先、ノードの出口、という層の合わせ技で説明しやすい失敗方です。当ブログの Netflix 稿・Disney+ 稿で既に扱った層分け思想を継ぎ、本稿はそのドメイン名と Warner 系のレガシー取り扱いに振っています。

Mihomo／Clash Meta 系は、ログから不足 分流ルールを足し込みやすく、ストリーミングの現場向けの修正に向きます。

各 OS 向けクライアントの入手先は ダウンロードページ に揃えています。まず DNS と接続層の取り違いを一巡させたうえで、環境に合ったビルドを導入すると、再生経路の再現と手戻りが大きく減ります。→ Clash クライアントを無料で入手し、ルールと DNS を自分の手で揃えた接続を試す