検索意図：プレビューシーズンに「OTA だけ」不安定になりやすい理由

developer.android.com や関連する静的コンテンツ・ナビゲーションは比較的軽量でも、OTA ペイロードや大容量のファクトリーイメージは別のホスト名・CDN エッジへ振られることがよくあります。半ルータ構成では、(A) HTML と認証まわりだけ PROXY に載り、(B) 実際のバイト列を返す Google CDN や googleapis／gstatic 系の行だけ DIRECT で細い uplink に直撃する、(C) あるいはその逆で、(D) DNS の解決結果と実際の TLS の SNIが別出口を指してしまう、といったパターンが出やすいです。Android 16 Beta のOTA は長時間・再開前提の転送になるため、わずかなセッション切断やタイムアウトがそのまま「更新に失敗しました」に見えます。

ここで最初に疑うのは RTT 単体よりも、同一デバイス内で複数ホストが別 Policy に割り当てられていないかです。Clash（Mihomo）の接続一覧で、同じ数十秒に発生した行同士のPolicy 列を横に並べて比較するのが実務的です。

通信の層：ポータル・認証・ペイロード・Pixel の更新チャネル

大まかには次の帯に分けて観測します。(1) ブラウザで読むドキュメントとナビゲーション（developer.android.com および関連サブドメイン）、(2) ダウンロード一覧やデベロッパー向け API／OAuth／アカウントに絡むホスト群、(3) ファクトリーイメージや SDK コンポーネントのような大容量バイナリ向けの別名（ログに googleapis、gstatic、googleusercontent、download、CDN のエッジ名などが混在する例）、(4) Pixel 実機のシステム更新（OTA）としてデバイス OS がGoogle の更新インフラへ直接張る経路（ゲートウェイルータに Clash がいる場合と、端末だけ別ネットワークにいる場合で見え方が変わります）。

Google I/O 2026 のようなイベント前後は、(1) の閲覧・検索と、(3)(4) の一括取得が重なるため、ルールの上から順にマッチする行のせいで (3) だけ制限付きノードに載る、という状況が起きやすいです。ホスト名はリージョンと時期で変わります。以下のルール断片は手元のログに出た FQDNへ置き換える前提の雛形です。

症状と接続ログでの見え方

再現手順の途中で Clash クライアントの接続一覧を開き、android、google、gstatic、googleapis、download などでフィルタします。developer 系の行だけ PROXY、ペイロード側が DIRECT のままになっている、あるいはその逆、が見つかると、「ページは読めるのにOTA のプログレスだけ進まない」説明がつきやすくなります。ADB やパソコン経由で取得する場合は、ホスト OS がプロキシを継がない経路が残っていないかも合わせて確認します。

fake-ip モードでは、ブラウザとシステム更新クライアントで名前解決の扱いがズレると、断続的にだけ古い宛先へ繋がることもあります。後述の DNS の節で、解決系と出口の一貫性を揃える前提を整理します。

DNS：fake-ip、nameserver-policy、端末ローカル DNS

Google 系ドメインは、見かけ上同じサービスでも複数の A レコードや別エッジに分岐します。Mihomo 系では nameserver-policy や redir-host 相当の設定で、developer.android.com と、実際にペイロードを返すCDN 名を分けて観測しやすくすることができます。ポイントは暗記した YAML の型ではなく、一連の失敗ログの再生中に「誰がどの名前を解決しているか」が一本化されているかです。Pixel がプライベート DNS（DNS over TLS）を使っている場合、ルータ側の Clash DNS と二系統になりやすいので、切り分けのときは一時的に端末設定とルータ設定の対応をそろえて試すと判断が早くなることがあります。詳細は トラブルシューティング全般も参照してください。

Mihomo ルール順：広い GOOGLE 行の下に隠れない

典型の失敗は、購読ルールに含まれる巨大な DOMAIN-KEYWORD,google 相当が先頭にあり、後段で書いた developer 専用行が評価されないことです。対策は、(1) ログに今回の OTA 試行で実在した FQDNを上の方に積む、(2) キーワード行が意図せず *.google.com を飲み込んでいないか確認する、(3) FINAL や GEOIP が先に通過させていないか、の三つです。開発者向けと一般検索・YouTubeなど別用途のホストをまとめないよう、策略グループを分けてログで追いやすくする運用が向きます。どの構成でも、同じ FQDN が行ごとに矛盾した Policyを指していないかを最後に再確認します。

ルール例（参考スニペット）

下は考え方の断片です。コピペ即運用はせず、必ず自環境の購読ルールと重複を確認し、実ログの主机名に合わせて置換してください。

# Example snippets — match your live Pixel / router logs; respect subscription order
rules:
  - DOMAIN-SUFFIX,developer.android.com,ANDROID_DEV_PROXY
  - DOMAIN-SUFFIX,android.com,ANDROID_DEV_PROXY
  - DOMAIN-SUFFIX,android.googleapis.com,ANDROID_OTA_CDN
  - DOMAIN-SUFFIX,googleapis.com,ANDROID_OTA_CDN
  - DOMAIN-SUFFIX,gstatic.com,DIRECT
  - DOMAIN-SUFFIX,googleusercontent.com,ANDROID_OTA_CDN
  - DOMAIN-SUFFIX,google.com,GOOGLE_MIXED
  - MATCH,PROXY

上の ANDROID_OTA_CDN = DIRECT は、ローカル ISP から特定 CDN への直経路に余裕がある地域向けの例です。逆に、DIRECT が不安定な回線では大容量行も PROXY に揃えた方が成功率が上がる場合もあります。まずは失敗率を下げるために出口を一つに揃え、その後に帯域最適化を入れる順序が扱いやすいです。認証やメタデータだけ通ってペイロードだけ宙に浮く状態を避けるのが主眼です。

TUN、VPN、Pixel／ルータのどこに Clash があるか

TUN モード（概要は TUN モードの記事）は、OS のルーティングからトラフィックを取り込み、取りこぼしを減らすのに有効です。一方で Pixel はVPN プロファイルやプライベート DNSが別レイヤーから経路を上書きします。ゲートウェイに Clashがあり、スマホはその LAN にだけつながっている場合と、スマホ単体に VPN アプリがある場合では、ログに出るホストとタイミングが異なります。Android に ClashMeta を入れる全体の流れは別稿の導入手順に譲り、本稿ではdeveloper.android.com と Google CDN／OTAというホスト軸に絞ります。新規で購読を足す場合は サブスクリプション取り込みの流れに沿い、ルールの追記は差分だけにすると切り戻しが容易です。

動作確認のすすめ方

手戻りを減らす順序の例です。(1) ブラウザで developer.android.com の狭い遷移だけを試す。(2) 小さめの SDK コンポーネントや数百 MB 級の試験ダウンロードで、同じ Policy が並ぶか確認する。(3) 実機の OTA に進む。長時間のフル OTA より、短い再接続試行でログ行を揃えてから夜間帯にまとめると安全です。いったん Clash をオフにした直結で症状が消えるかの対照実験で、上流かプロキシ配下かを先に二分してから DNS／ルールへ入ると迷走しにくいです。対照後はセキュリティ上必要なプロキシ必須運用へ戻してください。

本稿の位置づけ：WWDC＋Xcode 稿とのペア

WWDC 前後の Xcode・developer.apple.com と Apple CDN の稿では、macOS 側のツールチェーン取得を題材にしました。本稿は Google／Android のプレビューと開発者サイト、およびOTA／ペイロード配信にフォーカスします。セッション／CDN／DNS／TUNという切り分け枠そのものは共通なので、どちらか一方で整理した考え方を、もう一方のログにもそのまま転写できます。両方を触る場合は、ルール上でタグや策略グループを分け、購読ルールとの衝突だけに注意してください。

本稿は、正当な開発者向けドキュメント閲覧と、自分が所有する端末への公式手段によるアップデートを前提としたネットワーク最適化の整理です。利用規約に反する取得や、配布制限のあるリソースへの不正アクセスを助長する意図はありません。記載のドメイン例は将来変更される可能性があり、その保証を与えるものではありません。

まとめ

Google I/O 2026 に近いタイミングや Android 16 Beta のOTA が繰り返し失敗するとき、developer.android.com 周辺の会話的トラフィックと、Google CDN／ペイロード配信用ホストが Clash 上で別出口に割れているケースはよく見られます。接続ログで FQDN と Policy を横並びに揃え、DNS・ルールの上下関係・TUN と端末設定のレイヤーを順に整えると、プレビューシーズンのイライラする待ち時間を短縮しやすくなります。可視化しやすい Mihomo 互換クライアントで、購読と追記行の衝突にだけ気を付ける運用をお勧めします。

ルール編集の手戻りを減らしたい場合は、安定した UI とコア表示の整合が取りやすいクライアントから始めるのも一案です。→ Clash を無料ダウンロードし、developer 系と Google CDN の出口を揃えてから、もう一度 Android 16 Beta の OTA を試す