検索意図：会議前後に「取得だけ」が不安定な理由

developer.apple.com や developer.apple.com/download 周辺のHTML／認証は速いのに、マルチ GB の Xcode や、Command Line Tools、再配布用のドキュメント添付だけが時間切れ、あるいは何度リトライしても同じ割合で止まる。ここで最初に疑うのは、ラベル一つ上の RTT というより、ドメインごとに掛かっている Clash（Mihomo）の Policyが分岐しているかどうかです。Apple 側の設計上、ポータル本体とバイナリ配信用の別ホストは往々にして別名のまま、HTTP／2 や TLS のセッションも同じ「安定した出口」に乗っていないと、ブラウザの進捗表示だけ不自然に伸びることがあります。

本稿の対象は、主に macOS 上の Xcode／ターミナル、および HTTP プロキシや TUN の配下で作業する開発者です。Windows 単体向けの Microsoft Store 回りは、必要に応じて別稿を参照し、ここでは Apple の開発者用エンドポイント集合に絞ります。

通信の層：ポータル・認証・配信 CDN・SPM 取得

大まかに次の帯に分かれます。(A) HTML とナビゲーション（developer.apple.com 本体）、(B) アカウントと認証（idmsa.apple.com 等。実名は随時更新）、(C) 大容量の xip や補助ツール向けのバージン・CDN 名（ログに swcdn、download.developer、akamai、edgekey などの痕跡が出る例）、(D) Swift Package Index や github.com 経由の依存取得で、(A)(C) と別ルールに落ちうる層。WWDC 前後は (A) への書き込み型トラフィック（ブックマーク、検索、サンプル閲覧）と、(C) の一括ダウンロードが同時多発しやすく、ルールの上から順に当たる行のせいで (C) だけ 制限付きのノードに載る、というパターンが出やすいです。

注意として、ホスト名は季節とリージョンで変わります。以降のルール断片は手元の接続ビューに出た FQDNをそのまま置き換える前提の雛形に過ぎません。購読ルールに「Apple 開発者」等のまとまりがあれば、そこに加筆する方が衝突が少ないです。

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

再現手順中に、Clash クライアントの接続一覧を開き、apple、developer、swcdn、swift、github などをフィルタして同じ数秒に出る行同士の Policy 列を比較します。ここで (A) の行だけ PROXY、(C) 側が DIRECT のまま帯域の細い回線直撃、あるいはその逆、が見つかると、UI 上の「ページは開くのに xip だけ 0% 付近」が説明しやすくなります。ターミナルから curl -I を叩いても、システムプロキシを読まない挙勢の場合、ログに出ない行が残るので、ターミナルとプロキシ環境の既稿の観点とセットで見ます。

また fake-ip モード利用時、ブラウザと CLI で解決結果の取り扱いがズレると、断続的にだけ失効する、という形にもなり得ます。後述の DNS 節で、解決系と出口の一貫性を揃えます。

DNS：fake-ip、redir-host、クライアント解決

Apple 系のドメイン群は、同じ会話名でも裏向きで複数 A レコードに分岐する例があります。Mihomo 系では、nameserver-policy や redir-host 相当で、developer.apple.com と、実際のバイト列を返す CDN 名を分けて観測しやすい設定に寄せると、「解決は通ったのに SNI だけ違う」と気づきにくいケースを減らせます。ポイントは暗記した YAML の型ではなく、一連の再現中に、who resolves what が一本化されているかです。必要なら トラブルシューティング全般の手順に戻り、DNS だけ一時的に比較実験するのが安全です。

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

典型の失敗は、購読に含まれる巨大な DOMAIN-KEYWORD,apple 相当が上にあり、後段で書いた developer 専用行がマッチしないことです。対策は、(1) ログに今回の取得で実在した FQDNを上の方に積む、(2) キーワード行の掛かり方を確認し、想定外の *.apple.com を飲み込んでいないかを見る、(3) FINAL や GEOIP が、まだ分岐の話を始める前に通過させていないか、の三つ。開発者用と一般向け IDC／ネットスケープの混線を避けたい場合は、DEVELOPER 用の 策略グループを独立させ、帯域の大きい行だけ別ノード（または DIRECT）に寄せる二階建てにすると、意図が追いやすいです。どの構成でも、同じ FQDN が行ごとに矛盾した Policyを指していないかを、ログの最後で再確認します。

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

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

# Example snippets — always match your live logs; respect subscription order
rules:
  - DOMAIN-SUFFIX,developer.apple.com,DEVELOPER_PROXY
  - DOMAIN-SUFFIX,devimages-cdn.apple.com,DEVELOPER_CDN
  - DOMAIN-SUFFIX,swcdn.apple.com,DEVELOPER_CDN
  - DOMAIN,download.developer.apple.com,DEVELOPER_CDN
  - DOMAIN-SUFFIX,cocoapods.org,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,ghcr.io,PROXY
  - DOMAIN-SUFFIX,akamai.net,DIRECT
  - DOMAIN-SUFFIX,edgekey.net,DIRECT
  - DOMAIN-SUFFIX,icloud.com,PROXY
  - MATCH,PROXY

上の DEVELOPER_CDN = DIRECT は、自宅／オフィスから特定 CDN への直経路に余裕がある前提の例です。逆に、ISP 経由の DIRECT が遅い地域では、大容量行も PROXY へ揃えた方がスループットとセッションが安定する例も珍しくありません。まず失敗率を下げるために出口を一つに揃え、あとで帯域最適化を入れる、という順序が扱いやすいです。認証系だけ抜けて 大容量先だけ宙に浮くのを避けるのが、本稿の主眼です。

TUN、Xcode 内蔵 git、xcodebuild

Xcode や xcodebuild から出る Swift Package 解決、証明書・公证（notary）系、内蔵 git など、プロセスによって HTTP プロキシの継ぎ方が分かれます。取りこぼしを減らすには TUN モード（解説は TUN モード）を有効にし、同一デバイスの同じプロファイルで、まず狭い developer.apple.com 疎通から順に成功を重ねるのが定石です。新規導入は サブスクリプション導入の流れに沿い、ルール改変は差分だけ加えると切り戻しが容易です。

動作確認のすすめ方

手戻りを減らす順序の例です。(1) ブラウザで developer.apple.com だけ、狭い遷移に限定。(2) 小さな補助パッケージ（数十 MB 級）を同じ手順で再現できるか。(3) 大きな xip 取得に進む。長時間の一括より、短い試行でルール照合のログ行を揃えたあと、夜間帯のフル取得に進むのが安全です。いったん Clash をオフにした直結で症状が消えるか、の対照実験で 上流か Clash 配下かの二分を先に固めてから、DNS／ルールの微調整に入ると迷走しにくいです。対照後は、セキュリティ上必要な プロキシ必須ポリシーに戻してください。

本稿の位置づけ：iCloud 消費者稿との違い

既稿は、端末上の iCloud 写真・バックアップ・Apple Intelligence 拡張のような、消費者向けの同期・クラウド体験の束ね方を扱います。本稿は、developer.apple.com 起点のツールチェーン、サンプルとドキュメント、大容量 xip 配信、SPM・CLIにフォーカスし、同じ「Apple 分流」でも層の集合が違う点を明確にします。両方が必要な方は、ルール上でタグや策略グループを分け、衝突しないよう上から順の整合だけ取ってください。

本稿は、正当な Apple Developer プログラム会員の手元のネットワーク最適化を目的とする技術整理です。利用規約違反となる取得や、配布制限付きリソースの不正アクセスを助長する意図はありません。自己責任のうえ、契約上許された方法でのみ使用してください。記載のドメイン例は、将来の変更に対する保証を与えるものではありません。

まとめ

WWDC 2026 前後の Xcode／Command Line Tools／技術文書／SPM 取得の不調の多くは、developer.apple.com 周辺の会話的トラフィックと、大容量配信用 CDN 名が、Clash 上の別出口に乗ったときに起こりやすいです。接続ログで FQDN と Policy を横並びに揃え、DNS・ルールの上下関係・TUN による取りこぼしを順に直すと、会議前のリードタイム短縮に役立ちます。Mihomo 互換の可視化しやすいクライアントを使い、購読と追記行の衝突に気を配る運用をお勧めします。

安定した可視化と、ルール編集の手戻りの少なさを両立するには、定番のクライアント導入から始める近道もあります。→ Clash を無料ダウンロードし、developer 系と配信 CDN の出口を揃えてから、もう一度 Xcode の取得を試す