1. 症状：ログイン回りと「初期化」止まりは、経路分裂のサインになりやすい
Battle.net は起動直後から、アカウントセッション、カタログ、パッチメタデータ、チャンク配信、場合によっては Battle.net 内蔵のブラウジング要素まで、複数のホストへ並列にリクエストを投げます。トップは表示できてもサインインだけ終わらない、インストールの進捗バーが「初期化のまま」固まる——こうした挙動は、単一の帯域不足というより、一部サブドメインだけ別ルールに落ちているときに出やすいです。Clash の接続一覧に出るホスト名と、実際に選ばれた策略を突き合わせると、切り分けの初手が一気に早くなります。
まだ config.yaml の階層に慣れていない方は、先に サブスクリプション取り込みの記事で、プロバイダーと rules の流れを押さえておくと、以降の作業が読みやすくなります。
2. 通信の「層」：Blizzard 本体、認証、CDN、パッチ取得
実際の FQDN はクライアントの版や配信元で変化するため、ログに出た文字列を正とします。設計のメモとして、次のような層分けを頭に置くと、ルールを書き分けやすくなります。
| 層 | ざっくりした例 | 切り分けの着眼点 |
|---|---|---|
| ランチャー制御 | battle.net や blizzard を含む API 系 | 起動はするがサインインだけ回るとき、セッションと OAuth 周辺を疑う。 |
| アカウント / IdP | ブラウザウィンドウや埋め込みの認証遷移 | OS のプロキシを読まない認証枠と、Clash 経路が食い違うと完了しない。 |
| 静的とパッチ用 CDN | 各社 CDN のエッジ名、akamai や cloudfront 等の配下 | 「画面は出るのに取得だけ遅い」は CDN 帯の誤 DIRECT と相性がよい。 |
| 大容量配信 | download や patch を含む取得ホスト | 「初期化のまま」はメタ取得と本体 DL が別出口に分かれている典型。 |
重要なのは、一度ログインできたから以後は全部同じ出口と決め打ちしないことです。バックグラウンドの別スレッドが、見えにくい FQDN へ同時に飛びます。Steam・Epic とはドメイングラフが別物のため、Steam 向け CDN 分流や Epic Games Launcher 向けの記事のルールをそのまま流用するのは避け、Battle.net 専用のログから作り直すのが安全です。
3. Windows 上の取りこぼし：システムプロキシと TUN、ブラウザ枠
多くの環境で、OS のシステムプロキシに Clash の mixed ポートを割り当てる運用が一般的です。一方で、Battle.net は内部に複数コンポーネントを持ち、埋め込みの認証や、別プロセスの取得が、システムプロキシ解釈を分けることがあります。まず Clash 側で、システムプロキシか TUN のどちらでトラフィックを握るかを確認し、接続ビューで battle や blizzard を含む行が意図した策略グループに入っているかを見ます。Microsoft Store 系 UWP だけ特別、という線引きを理解するには UWP 回り込みと Clashも参考になります（Battle.net 本体は UWP ではないケースが多いですが、Windows での挙動理解に役立ちます）。
4. ドメイン収集：失敗操作を再現しつつ、ログの時系列で拾う
収集手順の骨格は次のとおりです。どれか一つに偏ると抜け漏れが出やすいため、併用してください。
- Battle.net を起動し、サインインを含むフルフロー、または止まるインストール／更新操作を、問題が出るところまで再現する。
- 同じ直後のタイミングで、Clash（Mihomo 搭載なら接続タブ）の接続行を時系列で追い、
blizzard・battle・明らかな CDN 名をメモする。 DIRECTや想定外のポリシーに落ちた行に印を付け、購読ルール内の「広いMATCH」の上に、自作ルールを挿入すべきかを判断する。- 大容量配信に入った直後に再度ログを眺め、新しく現れた FQDN だけ漏れがないか確認する。
ポート競合、コア未起動など汎用の不調は トラブルシュート全般へ。本稿は Blizzard 系の多面接続に焦点を当てます。
5. 推奨する切り分けの順序
- Clash の稼働、システムプロキシまたは TUN の有効、どちらで全体を掴むかを固定する。
- 接続ログで Battle.net 関連 FQDN が、意図したプロキシグループに入っているか、誤った
DIRECTが紛れていないかを確認する。 fake-ipを使う場合、DNS セクションの挙動を確認し、必要なら特定サフィックスにnameserver-policy等を当てて名前解決のブレを減らす。- ランチャー、認証、静的／CDN、DL 系を、十分に具体的な
DOMAIN／DOMAIN-SUFFIXとして、購読内の大きいDIRECTより上に、矛盾なく並べ替える。 - 経路が揃ったところで、揺れの少ないノードに固定し、短い間隔での自動切替を避け、TLS 再ハンドシェイクの悪化を減らす。
6. システムプロキシと TUN：取りこぼしのトレードオフ
システムプロキシは導入が速い一方、一部のネイティブ取得が WPAD や自前の SOCKS 解釈を別経路にする、といった差が出ることがあります。TUN は OS のルーティング層で掴むため一貫性は上がりがちですが、他社 VPN ドライバとの排他、権限まわりの手間があります。TUN の有効化手順は TUN モードの解説を参照し、有効化後に再接続ログで、Battle.net 関連 FQDN が揃ったかを再確認してください。
7. DNS／fake-ip：ルール前後での名前解釈のズレ
fake-ip は体感的な遅延を下げる一方、設定とルールの組み方次第で「ルールに渡る前の仮想 IP」と、実接続先の制御の間に、わずかな不整合が生じやすくなります。Blizzard のように、自社名義と大規模 CDN の両方をまたぐクライアントでは、そのズレがクライアント側では無限のローディングや「初期化のまま」に見えます。上流 DNS の選択、主要サフィックス専用の解決方針、そして ログで出た FQDN を一つずつ同じ出口に乗せることの三つをセットで見るのが、実務的な安定化の流れです。フィールド名はコアの版で差分があるため、利用中の Mihomo／Clash Meta の版に合わせたドキュメントを参照してください。
8. 分流ルールの考え方（記述例は置き換え必須）
購読先の静的リストに「国別の広い DIRECT」が先に入っていると、意図せず 国内直結に落ちる FQDN が紛れ込みます。対抗として、具体度の高い DOMAIN 行を、矛盾なく上側へ積み上げるのが実用的です。以下はあくまで例示です。必ず自環境の Clash ログに現れた FQDN を正として差し替えてください。Akamai や CloudFront の DOMAIN-SUFFIX を丸ごと載せると、Battle.net 以外のサイトに副作用を与える危険があるため、ログ上で実際に使われた下位名に絞るのが望ましいです。
# Example only — replace with hostnames from your Clash logs
rules:
- DOMAIN-SUFFIX,battle.net,PROXY
- DOMAIN-SUFFIX,blizzard.com,PROXY
- DOMAIN-SUFFIX,blzstatic.com,PROXY
# add patch/CDN FQDNs from your own logs, not broad CDN suffixes大容量帯域だけ、別名の proxy-groups（例：PROXY_CDN）に分け、制御面（例：PROXY_BNET）と分離すると、障害時の「層のどれが塞がっているか」の特定が早くなります。グループ名は設定ファイル内の定義と一致している必要があります。
9. 既稿との違い：Steam / Epic とのドメイングラフ
当サイトの Steam 向け、Epic 向けの記事は、それぞれ steampowered.com や epicgames.com 中心のグラフです。Battle.net／Blizzard は、アカウントとパッチ配信、社外 CDNの組み合わせ方が違い、PC で複数ランチャーを併用するなら、ホスト表をプロダクトごとに分けてメンテするのが混乱を防ぎます。GTA 系の Rockstar Games Launcher 向けの記事と同じく、検索意図は近いのに、コピー対象の FQDN は置き換え必須です。
10. ノード：瞬間の帯域より、往復遅延の揺れの少なさ
一時的に速く見えるノードでも、短いインターバルで RTT が大きく跳ねると、多数の小さな HTTP／HTTPS 要求や大きな再開付きの取得に不向きで、クライアントはタイムアウトに見えます。手動で比較的安定した回線に固定し、常時の「最速切替」は避けた方が、ランチャー挙動は落ち着きやすいです。プロトコル選びの大枠は プロトコル比較も参考になります。
11. 追加の落とし穴：LAN 共有、複数 VPN、hosts 改変、IPv4／IPv6
自宅内の他端末へ同じ Clash を配るなら、LAN プロキシで allow-lan とファイアウォールを確認します。Clash 以外の常駐 VPN を同時有効にしていると、ルートの奪い合いで ときどき直結が紛れ込みます。手で hosts を書き換えていると、一部 CDN だけ妙な IP に解決され、ルールの意図と食い違います。さらに、IPv6 が有効で、IPv4 だけがプロキシに乗ると、面によって出口が分かれ、表示が一貫しなくなることがあります。一度シンプルな単一路徑に戻してからログを取り直すのが早道です。
12. まとめ：証拠（ログ）で Blizzard 系ホストを一枚に揃える
Battle.net のログイン回りや「初期化のまま」は、単一のスイッチ一つ、というより、モード、DNS、ルール順、ノード揺れの積み重ねで起こりがちです。本稿の順序で接続行を点検し、ドメイン単位で出口を揃えていけば、「とりあえず全通信を一つのグローバル代理」より、再現性の高い改善に繋がります。2026 年も配信基盤は早く入れ替わるため、購読ルールに頼り切らず、四半期に一度、自分用の FQDN 表を更新する習慣があると安心です。接続ビューとルール編集をまとめて扱える Clash 系クライアントであれば、YAML を毎回手打ちする負担も下がります。Blizzard クライアントの認証と CDN を一つの設計思想で束ねたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める