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

2026：Notion／Notion AI を Clash で安定利用するドメイン分流と DNS（実測）

2025–2026 年もNotionはナレッジ管理と共同編集の定番ですが、ブラウザやデスクトップ／モバイルアプリでページは開くのに Notion AI だけ応答しない、同期が止まる、公開ページだけ真っ白といった症状は、しばしば単一ドメイン一行の PROXY では足りないホスト集合と、DNS（fake-ip・DoH）の取り違えとして見えます。本稿はClash（多くの場合 Clash Meta／Mihomo コア）側で、ドメイン分流と名前解決を揃え、Rule モードのログで再現する手順を日本語で整理します。ChatGPT／OpenAI 向け記事やClaude 向け記事が扱う別ベンダーのホスト集合と混ぜず、Notion の Web / API / 公開サイト / クライアント同期に焦点を当てます。インフラ側のエッジやサブドメインは更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。

なぜ「生成 AI 向けの汎用ルール」をそのまま流用しにくいか

Notionは、エディタ本体（notion.so 系）、公式 API（api.notion.com など）、公開ページ（notion.site 系）、計測や静的配信のためのCDN / サードパーティが同時に絡みやすい構成です。Notion AIは UI 上のボタン一つに見えても、バックエンド呼び出しやレート制御、ブラウザ拡張・デスクトップアプリの別経路が重なると、症状が「AI だけ」「同期だけ」「モバイルだけ」に分かれます。Clash の観点では「どのホストが DIRECT に落ちているか」「広い RULE-SET に先に飲まれていないか」「CLI や SDK がシステムプロキシを読まずに別出口へ出ていないか」が分岐点になります。チュートリアルでモードの前提を押さえたうえで、カスタムルールの書き方と併読すると、Notion 向けの例外を上に積む判断がしやすくなります。

すでに公開している Perplexity 向け記事やManus など AI エージェント向け記事は、検索意図の近い「別サービス」のホスト集合を扱っています。本稿はNotion／Notion AIに絞り、ノートの閲覧・編集と AI 機能、安定アクセスと同期の切り分けを重ねます。

Notion が扱うホストのイメージ（Web・アプリ・API・公開ページ）

ブラウザのメイン UIでは notion.so や www.notion.so が中心になりやすく、静的アセットや計測用に追加のサブドメインやサードパーティ CDN が混ざることがあります。公式 API連携やスクリプト、外部ツールからの呼び出しでは api.notion.com など別ゾーンの FQDNがドキュメントに載ります。公開ページ（notion.site など公開サイト用ドメイン）は、社内 Wiki と同じ出口に寄せたい一方、閲覧専用の読者向けに直結を優先したいケースもあります。いずれもインフラ変更で増減し得るため、検索で見つかるドメイン一覧は参考にとどめ、自分のログに出たホスト名を正としてルールを育てるのが長く使うコツです。

モバイルアプリやデスクトップクライアントは、OS のシステムプロキシや証明書ストア、バックグラウンド同期のタイミングがブラウザと異なり、同期だけ不安定に見えることがあります。HTTPS の SNI と実ホストの取り違えで挙動がおかしいときは、Clash Meta の sniffing と DNS の切り分けも併せて確認すると原因が絞りやすいです。

分流の土台：proxy-groups に「Notion 用」を置く

購読テンプレの汎用 PROXY を直接指すより、NotionProxy のような用途名のグループを select または url-test で用意し、rules からは常にその名前を参照するのが運用しやすいです。Web の閲覧と API 呼び出しを同じ出口に揃えるか、レイテンシや規約の都合でAPI だけ別グループにするかも、グループ名を分けておけば後から差し替えが容易です。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

ドメインルールの出発点（YAML 例）

方針として、(A) ユーザー向け Web・Notion AI と API・公開ページを同じ NotionProxy に寄せるのがシンプル、(B) 社内ドキュメントだけ直結にしたい場合は、GEOIP や広い RULE-SET との衝突をログで確認しながら例外を上に積む、が現実的です。(C) DOMAIN-SUFFIX,com のような広すぎる一括は他サービスへ波及しやすいので避け、notion.so やログで確認したサフィックスに絞るのが無難です。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、Notion 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (NotionProxy) and domains to your logs
  - DOMAIN-SUFFIX,notion.so,NotionProxy
  - DOMAIN-SUFFIX,notion.site,NotionProxy
  - DOMAIN,api.notion.com,NotionProxy

ブラウザ拡張、デスクトップ／モバイルアプリ、curl や SDK からの呼び出しは、参照するホスト名が UI と一致しないことが多く、本稿のリストとは必ずしも一致しません。その場合は接続ログに出た FQDN をそのまま DOMAIN や DOMAIN-SUFFIX で追加してください。画像やスクリプトの読み込みに別ドメインが混ざる場合も、ログに出た名前を足すたびに、安定アクセスの再現性が高まります。

DNS と fake-ip：ルールより前に潰れる「名前解決」と同期

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラー、同期の遅延・失敗に見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で notion.so や api.notion.com だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。CLI やコンテナから API を叩く場合、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案や、HTTPS_PROXY 環境変数の明示を検討してください。ルールの優先順位は、より具体的な DOMAIN を汎用の MATCH や広い RULE-SET より上に置く、という原則が API や長時間接続の取りこぼし防止に効きます。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Notion の AI だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 API キーやセッション Cookie はクライアント設定に平文で残りやすいです。リポジトリにコミットしない・共有端末では権限を絞る、などセキュリティ面はプロキシ設定とは独立して必ず確認してください。

段階実測：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから Notion を開き、同じ端末から curl 等で api.notion.com への疎通を試し、症状が再現するかを記録します。これで「ローカル回線やプロバイダ側」の要因も見えます。

  2. 2

    Rule に戻し、Web と API それぞれでログを読む

    ページ編集、Notion AI の実行、モバイル／デスクトップの同期の両方について、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエンドポイント変更にも追従しやすくなります。企業ネットや地域によっては特定ドメインへの到達性が制約される場合でも、出口の品質・DNS・ルールの三つを同時に疑うと早く収束しやすいです。

よくある質問

ブラウザは快適なのに API 連携だけ失敗する

ブラウザはシステムプロキシ経由でルールが効いているが、ターミナルやサーバーがプロキシ設定を読んでいないパターンです。環境変数、TUN、または実行ユーザの違いを確認してください。

Notion AI だけ応答が遅い・タイムアウトする

AI 呼び出しに使うホストが別ドメインに分かれ、意図せず DIRECT や遅いノードに落ちている可能性があります。ログに出たホストを追加し、該当行を上に移動して再確認してください。ノード側のタイムアウトも疑ってください。

職場・学校のネットワークでは？

組織ポリシーでプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

まとめ

NotionとNotion AIをClashで安定アクセスしたい場合は、openai.com や anthropic.com 向けに整理した分流ルールだけでは取りこぼしが出やすく、notion.so 系・API・公開ページ・クライアント同期に現れるホストを、ログで拾い上げてドメイン分流に落とし込むのが実務的です。本稿の例は出発点であり、ログに基づきルールを育てることが長く使うコツです。単一ベンダーのチャット中心の整理は ChatGPT の記事、AI 検索まわりは Perplexity の記事で別ホスト集合として扱っているため、混同せず参照してください。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。オープンソースの参照や Issue の確認は GitHub 等でも可能ですが、インストーラの主導線は本サイトのダウンロードページに寄せるのが、他の AI 向け記事とも揃った使い方です。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。

→ Clash を無料ダウンロードし、Notion と Notion AI 向けの分流と DNS を試す