1 なぜ ChatGPT 用ルールだけでは足りないのか
多くのプロキシ利用者は、まず openai.com や anthropic.com のような LLM ベンダー単位のドメインセットを Clash 分流に入れます。これ自体は有効ですが、Notion はアプリ本体・オフラインキャッシュ・リアルタイム同期・Notion AI の推論リクエストが、ブラウザ拡張やモバイルアプリ、デスクトップクライアントごとに別の TCP セッションとして現れます。結果として「OpenAI 向けルールは通っているのに、ワークスペースの同期だけ遅い」「社内 SSO のリダイレクトだけ別経路に落ちる」といった、プロダクト固有のホスト抜けが起きやすいのです。
2026 年時点でも、チーム向けナレッジ管理やコラボレーション需要は高く、Notion を前提にしたオンボーディング資料を社内 Wiki に載せる企業も少なくありません。そのような文脈では、個人のブラウザだけでなく会社支給 PC のシステムプロキシや TUN モードまで含めた一貫した経路設計が求められます。Mihomo コアを載せたクライアントでは、接続ログに実際の SNI が残るため、テンプレートの DOMAIN-SUFFIX に載っていない新しいサブドメインを発見したら、そこを足していく運用が現実的です。
2 ログイン・同期・API・公開ページ：役割ごとに分けて考える
トラブルシュートを速くするコツは、症状を「認証」「データ同期」「外部連携」「公開サイト閲覧」に分けて、それぞれが刺さるホスト名をメモすることです。ブラウザで notion.so にログインできる一方、Electron ベースのデスクトップアプリが別の証明書ストアやプロキシ設定を参照して失敗するケースはよく聞かれます。また、同期は長めの HTTPS／WebSocket 的な挙動になりやすく、不安定な出口ノードだと「止まったように見える」ことがあります。
- サインイン／セッション維持： ブラウザやアプリが
notion.so配下で Cookie や OAuth コールバックを扱う。企業の IdP 連携がある場合は、社内ポリシーで許可された SSO 用ドメインも同じアウトバウンドに揃える必要があります。 - クラウド同期と AI： アプリ本体の通信は多くの場合
notion.soおよび関連サブドメインに集約されますが、バージョンや機能フラグによって追加ホストが現れることがあります。Notion AI の応答が遅いときは、まず接続ログで該当ホストがどのポリシーにマッチしたかを確認します。 - Notion API／自動化： 公式ドキュメントでは REST が
api.notion.comを指すことが一般的です。CI やサーバレスから叩く経路と、デスクトップアプリの経路を混同しないよう、ルールではDOMAINで明示してもよいでしょう。 - 公開ページ（Notion Site）： 共有リンクは
notion.siteなどのホストになることがあり、社内 Wiki から外部公開ページへジャンプするだけの利用でも、ここが別ルールに落ちると「リンクは開くが埋め込みが壊れる」といった不整合が出ます。
3 まず束ねる：代表的なサフィックス
第三者のリストに頼る前に、次のような DOMAIN-SUFFIX をベースラインとして書き出すと運用が楽になります。notion.so はアプリと Web の両方で中核となり、makenotion.com はコーポレートサイトやキャンペーン系の参照に現れることがあります。添付ファイルや画像の配信には notionusercontent.com などの CDN 系ホストが使われる場合があり、同期の体感速度に直結するため、メインアプリと同じ品質のプロキシグループに寄せるかどうかを意識的に決めます。
日本語圏のチームでは、他ツールとの比較記事として NotebookLM や Perplexity の分流記事も参照されますが、これらは主に Google や検索系ドメインが中心です。Notion はワークスペースの実データがクラウド側にあり、同期の安定性が体験の中心になる点が異なります。ルールを増やしすぎると保守が難しくなるため、まずは上記サフィックスで「意図したアウトバウンドに乗っているか」を確認し、不足分だけ Rule Provider や手書きルールで埋めるのがバランスが良いです。
4 Clash 分流：DOMAIN-SUFFIX と YAML の例
以下は 例示です。NOTION_PROXY は実際のセレクタ名やポリシー名に置き換えてください。最終 MATCH より上に置き、国内限定ルール（GEOIP など）と競合しない順序を確認します。
# Place ABOVE the final MATCH rule. Replace NOTION_PROXY with your selector.
- DOMAIN-SUFFIX,notion.so,NOTION_PROXY
- DOMAIN-SUFFIX,notion.site,NOTION_PROXY
- DOMAIN-SUFFIX,makenotion.com,NOTION_PROXY
- DOMAIN-SUFFIX,notionusercontent.com,NOTION_PROXY
- DOMAIN,api.notion.com,NOTION_PROXY
DOMAIN-SUFFIX,notion.so は www.notion.so を含む多くのサブドメインをまとめてカバーします。一方で api.notion.com は別トップレベルドメインのため、DOMAIN で明示するか、自動化用のホストだけ別ポリシーにしたい場合はより上に細かいルールを置きます。社内ミラーだけ DIRECT にしたいホストがあるときも、具体的なルールを先に書くという Clash 共通の作法を踏襲してください。
モバイルとデスクトップの差
iOS／Android アプリは OS の VPN プロファイルや「Wi-Fi ごとのプロキシ」に従う一方、macOS／Windows のデスクトップ版は独自のネットワークスタックを持つことがあります。iOS の Stash のように端末全体をプロキシに載せる構成と、PC だけ TUN で吸い上げる構成では、同じ YAML でも見える症状が変わります。チームでテンプレートを配布するときは、「対象クライアント」と「プロキシモード（システム／TUN）」をセットで書いておくと誤解が減ります。
5 Rule Provider：購読リストと手元の追記
SaaS 向けの Rule Provider には海外プロダクトがまとめて入っていることがありますが、Notion のサブドメインが古い／欠けているバージョンも珍しくありません。購読 URL が更新されないまま放置すると、新しいエッジホストが MATCH 側の意図しないノードへ流れ、同期だけ遅くなることがあります。現場では「週次でルールを引き直す」「接続ログで未登録ホストを捕捉して手書きルールに追記する」の併用が安定しやすいです。
Mihomo では rule-providers とメインの rules: の評価順が設定次第で変わります。ドキュメント化したルールセットをチーム内 Git で管理し、DOMAIN-SUFFIX の追加をプルリクエストで受けると、ネットワーク担当とアプリ利用者の間で認識合わせがしやすくなります。すでに MCP や npm レジストリ向けに細かいルールを書いている環境では、同じリポジトリに Notion 用のファイルを分けておくとレビューしやすいでしょう。
6 Sniffer と HTTPS：ホスト名の取りこぼしを防ぐ
ポート番号だけでは判定できない経路では、Mihomo の Sniffer（スニファ）機能が SNI や TLS 情報からドメインを復元します。設定や運用を誤ると、意図せず別ポリシーへ振り分けられることがあるため、HTTPS／SNI を扱う記事で挙動を押さえてから有効化するのが安全です。特に Notion AI のように応答が遅延しやすい機能では、スニファのオーバーヘッドとノードのレイテンシが重なってタイムアウトに見えることがあります。
切り分けの実務では、「Sniffer オフで再現するか」「特定のドメインだけスニファ対象から外すか」を試し、ログ上の host フィールドが期待どおりかを確認します。ブラウザだけ成功してアプリだけ失敗するときは、ユーザーエージェントではなくTLS フィンガープリントや証明書チェーンの差の可能性もあるため、早合点せず複数端末で比較してください。
7 DNS／FakeIP：同期の「止まった」表示
ルールが正しくても、クライアントが参照するリゾルバと Clash の fake-ip 設定が食い違うと、一瞬だけ DIRECT に落ちたり、別リージョンのエッジへ向かったりします。Meta カーネル向け DNS のベストプラクティスで述べているように、DoH とフォールバック、国内ドメインの直結ルールを整理し、海外 SaaS をまとめて扱うポリシー名と DNS の挙動を一致させるのがコツです。
Notion の同期は、見た目には「同期中」アイコンが長く回っているだけでも、裏側では多数のリクエストが直列・並列に走っています。DNS の TTL が極端に短い環境では再接続が増え、結果として AI 機能のリクエストまで遅延する場合があります。出口ノードを変えて改善するか、DNS だけ別の信頼できるリゾルバに寄せるかを、ログのタイムスタンプ付きで比較すると判断しやすくなります。
8 切り分けチェックリスト
- ログインだけ失敗する：
notion.soと IdP ドメインが同じアウトバウンドか。ブラウザとデスクトップでシステムプロキシのオン／オフが揃っているか。 - 同期だけ止まる： 長時間 HTTPS が特定ノードで切れていないか。Sniffer と fake-ip の組み合わせでホストが取り違えられていないか。
- Notion AI だけタイムアウト： 接続ログに現れるホストがルールに含まれているか。別の海外 SaaS と同じセレクタか。
- API 連携だけ 401／403：
api.notion.comとトークン発行元の経路が分断されていないか。企業ネットワークのブレークアウトポリシーを疑う。 - 公開ページだけ開かない：
notion.siteが別ルールに流れていないか。コンテンツブロッカーと競合していないか。
9 まとめ
2026 年、Notion と Notion AI はオフィス向けナレッジワークフローの中核になりつつあり、Clash 分流でも「汎用 LLM ドメイン」だけではカバーしきれないホスト集合を意識する必要があります。本稿では notion.so・notion.site・api.notion.com などを DOMAIN-SUFFIX／DOMAIN で束ね、Rule Provider の不足を接続ログで埋める運用を推奨しました。Mihomo の Sniffer や DNS／FakeIP は強力ですが、設定次第で同期の安定性に影響するため、関連ドキュメントとセットで読み進めてください。
同じ「AI ツール」でも、ブラウザで完結するサービスと、デスクトップ同期が主体のサービスでは切り分けの観点が異なります。チーム内でテンプレート YAML を共有するときは、必ず実機ログでホスト名を検証し、ドキュメントに「観測日」とクライアントのバージョンを残すと後から楽です。クライアントの入手は当サイトのダウンロードページから行い、オープンソースの参照は別途 GitHub を使う、という住み分けが安全です。
一般的なプロキシより、ルール・DNS・ログを一体で扱える Clash 互換スタックの方が、SaaS の細かなホスト追加に追従しやすい場面が多くあります。出口ノードの品質とルール設計を両方そろえれば、ログインから同期、Notion AI まで一連の体験を途切れさせにくくできます。
