📖 チュートリアル ⏱ 約18分で読めます

2026 Meta AI・Llama（meta.ai）を Clash で——Facebook CDN とアカウント域名の分流・DNS を実測

Meta AI とLlamaファミリーは生成系 AI の主戦場のひとつとして、ウェブ側の公開入口が meta.ai を中心としやすく、同時に画像・フォント・バンドルの取得にFacebook／Meta が運用する CDNや、アカウント統合ではaccounts.meta.comとconnect.facebook.netに代表されるグラフ／ログイン系ホストが並走しがちです。2026 年時点でも、本文は表示されるがアセットだけ混線したり、ログイン画面だけ証明書警告が続くように見えたりするときは、「meta.ai は通っている」という見かけだけを信じず、実際に参照されているホスト名の束がDIRECT・遅いノード・意図しないRULE-SETに散らばっている典型です。Clash（多くの場合Clash Meta／Mihomoコア）では分流ルールが狭かったりDNS（fake-ipと公開 DNS／DoH の組み合わせ）が想定と違うと、部分的成功に見えることがあります。本稿はChatGPT／OpenAI API、Claude／Anthropic、Microsoft Copilotとドメイン集合を明示的に分離し、Meta 系だけの DOMAIN のまとめ方と段階的なログ実測に絞って整理します。チュートリアル全体とカスタムルール記事は前提の土台になります。利用規約・地域ポリシー・職場ルールは常に優先してください。以下の YAML とホスト一覧は製品構成の変更で変わり得ます。出発点として使い、自分の接続ログを正として育ててください。

症状の型：meta.ai と「そこだけではないホスト」を分ける

Meta AI をブラウザで開いたとき、(1)トップページの枠は表示されるがウィジェットやストリームがフリーズする、(2)サインイン済み状態でだけタイムライン取得がコケる、(3)画像・アイコン・アバターだけが割れる、という切り口に分類しやすいです。(1)(2) はアプリ論理用のホストとログイン／グラフ／課金などが別グループになり、(3) は CDN 上のオブジェクトだけが別出口にばらける——いずれも、「meta.ai と同一サフィックスだけ」規則にしていてもリスト不足が残っているサインです。開発者ツールのネットワーク列でfbcdn.net／scontent 系や connect.facebook.net が混ざるかどうかを最初に確認すると、規則の穴の当たりが付きやすくなります。

ホスト設計の出発点：メイン・アカウント・Facebook CDN

公開ウェブ側では meta.ai と www.meta.ai がそのまま表に現れやすく、モデルごとのヘルプ／ドキュメントは llama.meta.com や ai.meta.com が参照される構成も広く読まれています。Meta アカウントおよび SSO の導線では accounts.meta.com、広い意味で Facebook に接続されているフローの一部では graph.facebook.com が API 側に名前が載ります。CDN では *.fbcdn.net に加え写真・ユーザー生成コンテンツ向けに *.fbsbx.com や地域付きホストなどが並ぶことがあり、サフィックスだけで一覧化するより自分の環境で失敗している URL のホストを拾い上げる運用が向きます。埋め込みスクリプトでは connect.facebook.net が前面に現れやすいです。

方針として、(A) META_AI のような名前の proxy-groups をひとつ作り、この用途にだけ束ねて出口を統一、(B)DOMAIN-SUFFIX,meta.ai をまず上流に書き、アカウント側と CDN がログに増えてきた分だけ順にDOMAIN で足していく、(A)(B) いずれかから始めると運用がシンプルです。テンプレ付属の GEOIP をまとめて上書きするより、例外を自分のリストの上側に積むイメージは Mistral／Le Chat の分流記事 に近いですが、依存する名前の集合が欧州モデルとは別物です。Grok と X／Twitter の記事ともホスト集合は異なります。

proxy-groups：Meta AI 用途の出口だけ切る

購読テンプレの PROXY をすべての用途で共有すると、一覧に無い名前が規則の最後まで落ち自動選択やGEOIP 側に預かったままになりがちです。META_AI のようなグループを select または url-test で用意し規則からは一意に参照すると、ログの読み間違えが減ります。proxy-groups のガイドに沿って階層を深くしない限りでも、名前の転記ミスだけは最初に除外できます。

💡 ヒント テンプレ内の綴り（META_AI と MetaAi など）は大文字／小文字の区別に注意してください。コアにより差が出ます。

YAML 規則例（開始点のみ・ログと照合）

次のような形で、(1) メインサイト、(2) ドキュメント系、(3) アカウントとグラフ類、(4)Facebook CDN とスクリプトの束を分け、そのあと自分の環境ログで増減させます。# 以降のコメントは説明のみで、環境により不要な行は削除してください。

rules:
  # Adjust group names to your yaml; META_AI is illustrative only
  - DOMAIN-SUFFIX,meta.ai,META_AI
  - DOMAIN-SUFFIX,www.meta.ai,META_AI
  - DOMAIN-SUFFIX,ai.meta.com,META_AI
  - DOMAIN-SUFFIX,llama.meta.com,META_AI
  - DOMAIN-SUFFIX,accounts.meta.com,META_AI
  - DOMAIN-KEYWORD,facebook.net,META_AI
  - DOMAIN-SUFFIX,fbcdn.net,META_AI
  - DOMAIN-SUFFIX,fbsbx.com,META_AI
  # If sni-based rules are used elsewhere, mirror SNI/domain lists consistently

DOMAIN-KEYWORD,facebook.net は connect.facebook.net を含める幅が広いため、自分のリストで競合しないかを確認してから適用してください。狭めたければログに現れた名前を DOMAIN で列挙する方法に変えられます。また EDGE／HTTP3 と組み合わせたとき、同一ホストが別ポート経路になるケースがあるため複数ログを並べて判断します。競合しないよう、より具体的な名前を上流に載せます。規則の優先順位は カスタムルール記事の「上から評価」のとおりです。

DNS と DoH：fake-ip がルールと揃っているか

分流が正しくても、名前解決の段階で期待と異なる IP が挟まり、結果として証明書エラーに見えることがあります。dns で fake-ip を利用しているときは、アプリ側のブラウザ独自 DoH と二重になると挙動が読みにくくなります。META_AI で観たい名前だけ別の nameserver-policy に寄せるのは有効な一方、変更は一回ずつにすると切り分けが容易です。DeepSeek におけるウェブ／API の分離よりも、今回は FACEBOOK CDN とアカウント側の幅が異なるので、リストの広さに注意してください。

コンテナ／WSL／IDE などからのみ失敗するときは、ホストとは別レイヤーの環境変数（HTTPS_PROXY など）や TUN の有効範囲を疑ってください。TUN モードの記事とセットで読むと、トラフィックがコアに届いているか確認しやすくなります。

動作モード：Rule と Direct の線引き

日常運用は Rule モード。Global は一時的に「規則不足かノード品質か」を切り分ける用途に限定し続けるのが無難です。Direct は Clash を迂回した状態でページを読み込んだときとの差を見るベースライン計測として使うと効果的です。トンネル型 VPN と Clash を比較する場合はClash と VPN の違いも参考になります。

⚠️ 注意 規程でプロキシの迂回や特定サービスの利用自体が禁止されている環境では、技術的手法が可能でも従順に従ってください。

段階実測：ログに「ホスト」「ルール」を残す

  1. 1

    Direct または停止でベースライン

    まずブラウザで meta.ai を開き、開発者ツールで主要ホストとステータスを控えます。CLI で HTTPS 疎通を試す場合は、自分の許可済み証明書とレートだけに注意してください。

  2. 2

    Rule で再現し一覧と照合する

    同じ操作を繰り返し、コアの接続ログで向いていたドメインとマッチした行をメモします。一覧に無い名前が増えれば、それが次に追加すべき候補です。

  3. 3

    一行ずつ規則を足して縮める

    一度に広い DOMAIN-SUFFIX を複数増やさず、挙動ごとに確認します。上流へ移すべきときはより具体的な行を上位へ移します。

  4. 4

    DNS ログまたは追跡を併ける

    失敗ホストだけ名前解決がおかしいなら規則より先に DNS を直します。公開 DNS と DoH で結果が異なるときはフェイルオーバーとキャッシュにも注意してください。

このサイクルを本稿では「分流を育てる」実測と呼んでいます。検索で拾った第三者一覧はヒントまでにとどめ、いまの自分の環境ログを基準に更新してください。

よくある質問

CDN を束ねすぎないと不安だが、束ね過ぎると他サイトまで変わった

fbcdn.net は影響範囲が広いので、問題のあるホスト名がログで特定できればDOMAIN で切ります。広さと副作用の綱引きになります。

ログインは通るが会話処理だけタイムアウトする

meta.ai とは別ホストでの API を叩いている可能性があります。開発者コンソールのネットワークで最終応答だけ別ドメインになっていないか確認してください。

ChatGPT と同じセットを流用してよいか

モデル側の名前は異なり、Facebook／Meta CDN とアカウント側のセットが増えます。ChatGPT／OpenAI 向けの規則をそのまま当て込んでも不足しがちです。

まとめ

Meta AI／Llamaをmeta.ai経由で使うワークフローでは、本文以外にFacebook CDNとグラフ・アカウント関連のホストまで含めFQDN が分散しやすいため、単一パターンだけの規則に頼ると部分的にのみ成功しているように見えがちです。MihomoとDOMAIN／RULE-SET、さらにDNSを一体で読むと、その「足りない一つ」を埋めやすくなります。オープンモデル配布側の視点では Hugging Face 向けの記事 と役割分担が異なります。

クライアント本体の入手や更新履歴は 本サイトのダウンロードページ に揃えると、記事での例と環境も追いやすくなります。ソースコードの参照だけは公開リポジトリでも構いませんがユーザー向けの入手先は本站を第一にしてください。総トンネルを常時張るだけのサービスより、用途単位で出口を読み分ける点でClash の運用に向く場面が多くなります。

→ Meta AI と Facebook CDN に合わせた分流を試す——Clash を無料ダウンロード