1 なぜ「アップル専用」の分流リストが要るのか
Apple のサービスは単一の *.apple.com に収まらず、iCloud のストレージ・CloudKit・プッシュ通知・App Store／TestFlight の mzstatic 系 CDN・将来の Apple Intelligence 向けホストなど、解像度の違う名前が並びます。大手生成 AI（OpenAI、Google、Microsoft 等）向けに既に別リストを持っている構成でも、Apple だけ別ポリシーにしたいケースは珍しくありません。例えば、社内プロキシでは一般 Web が許可されていてもクラウド推論系だけ制限されている、逆に「中国大陸向けアプリの回国直行」記事（RedNote／小紅書のように）とは目的地が異なる、といったレイヤの違いです。
ここでのゴールは、本記事が万能の最終リストを保証することではありません。Clash Meta／Mihomo で「どの名前をどのポリシーに寄せるか」の設計パターンと、手元で不足ホストを発掘する手順を揃えることです。Apple 側のエンドポイントはアップデートで増減するため、Rule Provider の定期取得と接続ログの突合をセットで回せるようにしておくのが安全です。
2 ドメイン棚卸し：iCloud・Siri・共通インフラ
実務では次のような束に分けてメモすると整理しやすいです。第一の束は icloud.com とそのサブドメイン、icloud-content.com、セットアップや認証に絡む setup.icloud.com／identity.apple.com 周辺です。第二の束は apple.com 本体と apple-cloudkit.com、デベロッパ向けやバックグラウンド同期に使われるホストです。第三の束は CDN 系で、例として cdn-apple.com、ストア画像やアセットに見られる mzstatic.com などがあります。第四の束は通知・デバイス管理寄りで、push.apple.com をはじめとする固定名や、環境によって現れる apple-dns.net のような名前です。
Siri や将来さらに前面に出る Apple Intelligence 向け通信は、公開情報だけでは完全な一覧化が難しい部分があります。設計としては、上記の共通インフラをまず安定して片付け、新機能利用時には connection ログで「実際に出てきたホスト」を DOMAIN／DOMAIN-SUFFIX に追記するループを回すのが現実的です。ワイルドカードに頼りすぎると不要なサブドメインまで同じ出口に寄るため、運用で効果を見ながらsuffix の粒度を調整してください。
.yaml にべた書きするか、Git 上の raw テキストを rule-providers で引くかは好みです。チームで共有するなら Provider 化して 更新間隔を揃えるほうが衝突が減ります。
3 Rule Provider と DOMAIN-SUFFIX の実装例
Mihomo では rule-providers に behavior: domain またはクラシックのリスト形式を指定し、rules 側で RULE-SET,プロバイダ名,ポリシー と読み込みます。以下は例示用の抜粋です。実環境ではホストを増減し、ポリシー名（例：PROXY、Apple-AI セレクター）を自分のプロファイルに合わせてください。コメントは仕様に従い英語のみとします。
rule-providers:
apple-core:
type: http
behavior: domain
url: "https://example.com/rules/apple-core.txt"
path: ./ruleset/apple-core.yaml
interval: 86400
rules:
- RULE-SET,apple-core,Apple-Policy
# ... your other rules ...
# apple-core.txt — behavior: domain: one suffix per line (no DOMAIN-SUFFIX prefix)
# icloud.com
# icloud-content.com
# apple.com
# apple-cloudkit.com
# cdn-apple.com
# mzstatic.com
# apple-dns.net
リモート URL を自分でホストできない場合は、type: file とローカルパスに切り替えて同じ内容を置いても構いません。購読全体を触りたくないときは mixin／上書きのように差分だけ載せる層を用意し、ベース設定はそのままにする手法も有効です。
4 ルール順：広い GEOIP より前に載せる
よくある失敗は、Apple 向けの細かい suffix を足したつもりが、より上にある GEOIP や広い GEOSITE、最終 MATCH に先に吸われるパターンです。Clash 系は原則上から最初の一致なので、意図したポリシーに落としたいドメインほどリストを上側へ寄せます。既存の「国内直行」「広告ブロック」「AI 専用プロキシ」など別カテゴリの RULE-SET との優先順位も、一枚の紙に書いてから YAML に落とすとミスが減ります。
HTTPS で最初からドメインが見えず IP ベースのルールに滑り込む場合は、Sniffer と SNI の設定がボトルネックになることがあります。アップル CDN のように同一 IP を共有していると、嗅探なしで誤った出口に付く事象も起こり得るため、ログで SNI 列が期待どおり出ているかを確認してください。
5 DNS：FakeIP・DoH・端末側の Secure DNS
ルールが正しくても名前解決がコアの外で完結していると、分流が効きません。FakeIP を使う構成では fake-ip-filter に iCloud 周りを誤って入れていないか、逆に取りこぼしがないかを DNS・FakeIP のベストプラクティスの観点で見直します。macOS や iOS 端末では OS の「プライベートリレー」やブラウザのセキュア DNS が別経路を作るため、症状が端末だけで起きるときはまずそのレイヤを疑うと早いです。
複数の nameserver を切り替えている場合、ある問い合わせだけタイムアウトし続けるとアプリ側は「ログインできない」「Siri が応答しない」に近い表示を出します。DNS ログ（短時間だけ log-level: debug）と、接続表 (external-controller と Yacd）を並べて読むと、失敗が DNS かルートかの切り分けがしやすくなります。
6 検証手順：期待どおりのポリシーに乗っているか
設定を反映したら、次の順で確認するとよいです。まず GUI かダッシュボードの接続一覧で、該当アプリ／ブラウザが Apple 関連ホストに接続した瞬間のルール名と出口をメモします。次に、サファリやシステム設定で iCloud サインインを試し、失敗したホスト名をログから拾ってリストに足します。三番目に、意図しない DIRECT や別リージョンのプロキシに落ちていないか、同一操作を二度繰り返して再現性を見ます。
コマンドで素早く見る場合は、TUN またはシステムプロキシ経由で curl や署名確認用の軽い HTTPS リクエストを投げ、応答コードと経路を併記してメモする方法もあります（証明書エラーが出る URL はアプリの実通信と一致しないこともあるので、必ずしも万能ではありません）。長期的には Rule Provider の interval を適切に保ち、Apple 側の変更に追従できる運用にしておくのがよいです。
7 端末リージョン・機能フラグ・リスト鮮度
Apple Intelligence 等の利用可否はアカウント・端末・地域ポリシーに依存し、プロキシだけを直しても機能が有効にならないケースがあります。ネットワーク運用としては「通信は通るが機能フラグがオフ」という区別をしておくと混乱が減ります。また iCloud Private Relay が有効だと、見えているエンドポイントのパターンが通常時と変わり、自作リストとの突合が難しくなる点にも注意してください。
本稿のリストは出発点です。コアやクライアントのバージョンアップ、GeoIP／GEOSITE のデータ更新 (手動更新の手順) と同様、定期メンテナンスが前提になります。社内ドキュメントに「最終確認日」と「追加した suffix」を書いておくと、次の担当者への引き継ぎが楽です。
8 まとめ
Apple Intelligence・Siri・iCloud を安定して使いたい場面では、単一ドメインだけでなく icloud／apple／CDN／通知を横断した suffix 束を Rule Provider 化し、ルール順・DNS・Snifferをセットで整えるのが効きます。Google や Microsoft の生成 AI と別物の名前空間であることを意識し、専用リストを持つ設計にすると運用が単純になります。
GUI とログの両方が揃った Clash 互換クライアントなら、本記事の手順をそのまま試行錯誤のテンプレートにできます。インストールパッケージは信頼できるビルドを本站のダウンロードページから選ぶのが安全で、オープンソースの参照は GitHub で十分に可能ですが、パッケージの第一入手先は本站を推奨します。同類ツールと比べても、プロファイルとログを一体で扱える製品はトラブル時の立て直しが速く、長期運用に向きます。
