1. 症状の読み解き：「同期中」は単一障害ではない

写真やバックアップのプログレスが長時間止まるとき、裏側ではメタデータの照合、チャンクのアップロード、デバイス間の状態同期、天気や探すの位置情報まわり、さらに 2025–2026 年にかけて利用範囲が広がった Apple Intelligence 関連の補助推論やコンテキスト取得が並列に走っています。どれか一系統がタイムアウトしてリトライを繰り返すと、ユーザーにはただの「同期が終わらない」やウィジェットの更新停止に見えます。Clash の接続一覧に出るホスト名と実際に選ばれた策略を時系列で並べると、「認証はプロキシで通っているのに、CDN 上の大きなペイロードだけ DIRECT で詰まっている」といった部分的成功が想像以上に早く見えてきます。まずは一枚岩の「Apple＝全部同じ経路」という想定でルールを書かない前提を共有します。

YAML の骨格やルールモードをまだ把握していない場合は、先にサブスクリプション取り込みの記事で設定ファイルの流れを押さえておくと、以降の手順が読みやすくなります。

2. プッシュ・iCloud・Siri／AI・CDN を「層」に分ける

以下は設計メモとしての区分であり、実際のサブドメインは環境で変わります。Apple はHTTPS の制御面とオブジェクト配信面を分けやすく、さらに通知やバックグラウンド更新でホストが増えます。

層イメージ切り分けのポイント
プッシュ・デバイス管理通知の維持、デバイス状態ログインは通るのに通知だけ遅い／届かないとき、長寿命接続と別経路になっていないかを疑う。
iCloud コアicloud.com、CloudKit 相当、バックアップのセッション「設定は開けるのにバックアップだけ進まない」とき、広い DIRECT より上に具体ルールが必要か。
Siri／Apple Intelligence 周辺音声・意図推理解析、補助クラウドオンデバイス処理と併用する通信が増えるほど、DNS とルール判定のズレが効きやすい。
CDN・静的取得大容量ペイロード、地域エッジ小さい JSON は即時でも、写真の再取得だけ遅いときに CDN サフィックスが別策略に落ちていないかを見る。

2026 年時点でも OS と地域でエンドポイントは変わり得ます。購読ルールに頼り切らず、自分のログで一度表を作り直すのが安全です。

3. macOS と iPhone：プロキシの見え方の違い

macOS では「システム設定のプロキシ」や Clash のシステムプロキシ拡張、TUN の組み合わせで、ターミナルや一部 CLI がまだ直結する例があります。CLI まわりはターミナルと環境変数の記事も参照してください。一方、iOS は VPN プロファイルや「デバイス管理」下のプロキシ、キャリアの差で経路の見え方が変わります。いずれも接続ビューに出るホスト名を正にし、ブラウザで apple.com が開けるからといって iCloud のバックグラウンドセッションまで同じ経路とは限りません。

4. ドメイン収集：バックアップ直前と写真スクロールを分けてログを取る

収集の基本は次の流れです。「iCloud バックアップが止まる」再現と「写真だけサムネが出ない」再現は別シナリオとして切り出すと読みやすくなります。

  1. Clash を起動し、システムプロキシまたは TUN を有効化する。併用中の別 VPN は一旦切る。
  2. 設定アプリからバックアップを手動開始するか、写真アプリで年別ビューを素早くスクロールして同期を促す。
  3. 接続ビューで同時刻付近のホストをメモし、DIRECT や想定外のポリシーに落ちている行に印をつける。
  4. 購読ルールのどの行より上に自作ルールを置くべきかを検討する（広い国内 DIRECT より上が定石）。

ポート占有やコア起動失敗など汎用トラブルはトラブルシュート記事へ。本稿は Apple 特有のマルチドメイン構成に焦点を当てます。

5. 推奨する切り分け順序

  1. Clash が起動していること、システムプロキシかTUNのどちらでトラフィックを握っているかを確認する。
  2. 接続ログで Apple 関連ホストが意図したポリシーグループに入っているか、誤った DIRECT がないかを見る。
  3. fake-ip を含む DNS 設定を確認し、必要なら特定サフィックスへ nameserver-policy 等を当てて名前解決のブレを減らす。
  4. 制御面（apple.com／icloud.com 系）と CDN 面をホスト／サフィックス単位でルール化し、購読ルール内の広い DIRECT より上側に矛盾なく配置する。
  5. バックアップと写真プレビューを別々に検証し、必要なら別ポリシーグループへ振り分ける。

6. システムプロキシと TUN：取りこぼしを減らす

システムプロキシは手軽ですが、プロキシ設定を読まないデーモンや、別ドライバの VPN と併用すると見かけ上の経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで Apple 関連ホストがすべて期待どおりの経路になったか検証してください。

7. DNS／fake-ip：名前解決とルール判定のズレ

fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。Apple のようにサブドメインと CDN が多いサービスでは、軽いズレでもクライアントがリトライを繰り返し、ユーザーにはただの「同期中」や進捗の停滞に見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、ログで頻出する主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。

8. 分流ルールの考え方（記述例は置き換え前提）

購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。Akamai や Fastly など共有 CDN を丸ごとプロキシに載せると、他サービスへ副作用が出る場合があります。ログに出た特定サブドメインに絞るか、ルールセットの細分化を検討してください。

# Example only — verify hostnames in your Clash logs before use
rules:
  - DOMAIN-SUFFIX,apple.com,PROXY
  - DOMAIN-SUFFIX,icloud.com,PROXY
  - DOMAIN-SUFFIX,apple-cloudkit.com,PROXY
  - DOMAIN-SUFFIX,mzstatic.com,PROXY

実宛先が IP 直指定になるケースでは、ドメインルールだけでは足りず、ログに出た IP レンジの検討が必要になることもあります。その場合は誤ルーティングのリスクが高まるため、最小限の範囲に留め、必ず接続ログと突き合わせてください。グループ名は proxy-groups に定義済みである必要があります。

9. Netflix／Claude 向け記事との違い

当サイトの Netflix 記事は、ストリーミングと地域カタログのマルチドメインが中心です。Claude 記事は特定 AI ベンダーにスコープを絞っています。本稿は OS 組み込みの Apple サービスに焦点を当て、プッシュ・iCloud・CDN・Siri／Apple Intelligence 周辺の両方を扱います。用途が違う記事を併用する方は、それぞれ別のホスト表を持つと混乱が減ります。

10. ノード選定：帯域より「揺れの少なさ」

スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、長時間のバックアップや再開可能な転送には不向きです。TLS の再ハンドシェイクが増え、クライアント側はタイムアウトや「同期中」として現れます。手動選択で様子を見たり、Apple 系を安定路線に固定するのが実用的です。プロトコル特性の比較はプロトコル比較記事も参考になります。

11. 追加の落とし穴：iCloud Private Relay、IPv6、MDM

iCloud Private Relay を有効にしていると、意図しない経路や DNS の挙動と干渉することがあります。検証時は一時的にオフにして差分を見るのも有効です。IPv6 が有効な回線では、IPv4 側だけプロキシに乗っているといったデュアルスタックの偏りも起きます。企業や学校の MDM 配下ではプロキシや証明書の方針が優先されるため、その場合は管理者のルールに従う必要があります。別 PC へプロキシを配る場合は、LAN プロキシの記事で allow-lan とファイアウォールの要点を押さえてください。

12. まとめ：証拠ベースで Apple と CDN を束ねる

Apple Intelligence の利用拡大や iCloud への依存が高まる 2025–2026 年において、写真・バックアップ・天気などが「同期中」のまま進まない症状は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。購読ルールに頼り切らず、自分の環境で一度ホスト表を更新する習慣を持つと安心です。

接続ログとルール編集を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど長く運用しやすい印象です。Apple エコシステムを安定して使いたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める