Notion AI と同期がぐるぐる？Notion・AWS ドメインを Clash（mihomo）で分流する実測（2026）

1. 同期と Notion AI が「回り続ける」典型原因

第一に、通信が単一ドメインに収まっていないことです。ブラウザやデスクトップアプリの表層では notion.so に見えていても、裏側ではWebSocket や REST、ファイル取得、AI 推論のフロント用ホストが分かれ、さらにAmazon S3 や CloudFront のような CDN 名へ飛ぶケースがあります。ルールでメインだけをプロキシに載せ、添付や静的アセットが別経路のままだと、本文は開けるのに同期インジケータだけ回るといった切り分けが難しい症状になります。

第二に、策略がリクエストごとに変わることです。MATCH や広い GEOIP の下でノードが自動選択されていると、短い API だけ別ノードへ落ち、サーバー側のレート制限やセッション扱いとぶつかることがあります。体感では「Wi-Fi を切り替えたら直った」のように見え、ネットワーク全般の問題に見えがちですが、実際は出口のばらつきであることも多いです。

第三に、DNS モード（fake-ip など）と実接続の評価対象がずれると、ルールが効いているように見えてTLS が別 IP で張られるなどの不整合が起きます。HTTPS は SNI にドメインが載る一方、評価が IP ベースに寄ると意図しない策略へフォールバックしやすくなります。ここは Sniffer と mihomo ログで確認するのが近道です。

本稿は技術的な名前と出口を揃える観点に限定します。サービス利用規約や地域ポリシーへの適合は、利用者自身の判断と事業者の案内に従ってください。

2. ChatGPT / Claude 稿との違い（知識ベースと AWS CDN）

当サイトの ChatGPT 向け記事や Claude 向け記事は、対話型モデルのフロントと APIにフォーカスします。一方 Notionは、ドキュメント同期・埋め込み・ファイル倉庫・AI サイドパネルが同時に動くため、OpenAI や Anthropic だけを束ねても足りない場面が普通にあります。加えて、添付やプレビューは AWS の一般的なホスト名へ飛ぶことがあり、「Notion 用」と「AWS 全域」のバランスが難しいのが本テーマの特徴です。

Cursor 向けの稿は npm や IDE マーケットのように開発者エコシステムが前面です。Notion はナレッジワーカー全般が触るため、ブラウザ拡張や社内 SSO と同居する別アプリが絡みやすい点も考慮し、ルールを広げすぎない運用を推します。

購読の取り込みは サブスクリプション導入ガイドを参照しつつ、以下では追記位置と評価順に注意します。広い MATCH より上に、Notion 用の細かい行を置くのが基本です。

3. まず束ねるドメイン：Notion 本体と添付・API

ドメインはプロダクト改修で変わり得るため、次の一覧は切り分けの出発点として読み、開発者ツールのネットワーク欄やコアログで実際のホスト名を確認してください。まず外せないのは notion.so と www.notion.so、公開ページやフォームで見かける notion.site です。API 連携を使う場合は api.notion.com が別経路になりやすいので、自動化スクリプトとブラウザで挙動が違うときはここを疑ってください。

画像やアセットでは notionusercontent.com や prod-files-secure.s3.us-west-2.amazonaws.com のようなリージョン付き S3 名がログに出ることがあります。Notion AI のフロントはメインドメイン側に寄りがちですが、補助的な計測や外部スクリプトが別名になる場合もあるため、失敗している URL のホスト部分だけをメモしてルールに足すのが安全です。

ワークスペースごとのサブドメイン（例：*.notion.so）は DOMAIN-SUFFIX,notion.so でまとめて拾えます。社内ポータルから シングルサインオンへ飛ぶ構成では、IdP 側のドメインも別途必要になるため、Notion 専用策略に SSO 全域を載せないよう注意してください。

4. AWS・CloudFront をルールに載せるときの注意

amazonaws.com や cloudfront.net はインターネット上のあらゆるサービスが共有する名前空間です。安易に DOMAIN-SUFFIX,amazonaws.com をプロキシへ送ると、社内の別ワークロードまで同じ出口に乗る副作用が大きくなります。実務では、ログに出たフルホスト名を DOMAIN ルールで個別指定するか、Notion が使うと分かっているプレフィックスに限ってサフィックスを切るのが無難です。

CloudFront はエッジ最適化のためホスト名が増殖しやすく、かつ他社サービスと共有されることもあります。広い DOMAIN-KEYWORD,cloudfront は誤爆のリスクが高いので避け、問題のリクエストに紐づく実名をルールプロバイダや手書きルールに追加する運用が現実的です。

Global Accelerator（awsglobalaccelerator.com）や Certificate Manager 周辺の名前が混ざる環境もあります。TLS エラーとタイムアウトを混同しないよう、まずは どのホストがどの策略にマッチしたかをログで確定させてから広げる順序がおすすめです。

5. mihomo ルール例：専用策略へ DOMAIN-SUFFIX

実務では 「Notion 用」の策略グループを一つ用意し、メインと API、ユーザー内容物のドメインをそこへ送る形が扱いやすいです。TUN モードでは OS 全体が対象になるため、プロセス名でアプリだけを分ける手もありますが、ブラウザ利用では効かないのでドメイン束ねが主戦場になります。

以下は構造の例です。プロキシ名や実在するドメインは環境に合わせて置き換え、S3 名はログで確認したものに差し替えてください。コメントは英語表記としています。

# proxy-groups: stable exit for Notion + attachments
proxy-groups:
  - name: NOTION
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: keep above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,notion.so,NOTION
  - DOMAIN-SUFFIX,notion.site,NOTION
  - DOMAIN-SUFFIX,notionusercontent.com,NOTION
  - DOMAIN,api.notion.com,NOTION
  - DOMAIN-SUFFIX,makenotion.com,NOTION
  - DOMAIN-SUFFIX,s3.us-west-2.amazonaws.com,NOTION
  - MATCH,PROXY

s3.us-west-2.amazonaws.com は例示です。手元のワークスペースでは別リージョン名になることがあるため、必ずログの実名に合わせてください。ルールの評価順は ルールルーティング解説のとおり、細かい行を広い MATCH より上に置きます。購読ルールの末尾に追記するだけでは効かないことがある点に注意してください。

6. DNS・fake-ip 校正と Sniffer の補助線

fake-ip モードでは、アプリが見ている名前とコアがルール評価に使う情報が環境差でずれやすいです。Notion のように長命接続（同期）と短い HTTPS が混在するアプリでは、そのズレが「たまに同期が止まる」として現れます。まずは redir-host や Sniffer の設定がクライアントの推奨に沿っているかを確認し、debug 相当のログでマッチ結果を追ってください。

Sniffer は TLS ClientHello の SNIを手掛かりに、IP ベースで誤マッチしていた通信を本来のドメインルールへ戻す補助になります。副作用や優先順位は Sniffer 解説記事で詳しく扱っています。本稿では Notion 特有の添付ホストのばらつきとセットで読む、という位置づけです。

TUN を併用する場合、DNS ハイジャックと OS のスタブリゾルバの組み合わせで二重解決になっていないかも確認します。TUN モードの解説を参照し、名前解決がどこで行われたかをログに残すと、あとからルールを足しやすくなります。

7. 実測チェックリスト（ログの見方まで）

実測では次の順が扱いやすいです。（1）問題再現中にコアログを開き、失敗または遅延しているホスト名をメモする。（2）そのホストが 意図した策略（例：NOTION）にマッチしているかを確認し、別の広いルールに吸われていれば順序を修正する。（3）マッチは正しいのに遅い場合は、その策略内のノードを入れ替え、url-test の間隔や許容遅延を調整する。（4）HTTP 403 や明確な地域メッセージが出ていれば、経路以前の要因を疑う。

ブラウザ利用では 拡張機能が追加リクエストを発行していることがあり、Notion 本体とは別ホストがログに混ざります。拡張を無効化して再現すると切り分けが速いです。デスクトップアプリでは、アップデート配布ドメインが本編と異なる場合があるため、更新直後だけ不安定ならその線も疑ってください。

チーム運用では、「Notion 用に決めたノード名」と追記したサフィックス一覧を社内ドキュメントに残すと、個人設定の差による切り分け地獄を減らせます。ルールは最小追加・ログドリブンを徹底し、広すぎる AWS サフィックスは避けるのが長く安定するコツです。

8. まとめ

Notion / Notion AIのつながり悪さは、メイン UI・同期・添付・AIが異なるホストへ分散しやすいことと、AWS の共有ドメイン空間が重なると、原因が見えにくくなります。まず mihomo で Notion 系を専用策略に束ね、ログで実名を拾いつつ S3 や CDN を最小限だけ追加し、DNS・fake-ip・Snifferで名前と出口を一致させる——この流れが、対話型 AI 単体の記事と重ならない越境ナレッジワーク向けの補助線になります。

同じ Clash 系クライアントでも、コアの世代と GUI の表記は移り変わります。手元の環境を最新に近づけ、購読とルールを整理したうえでログを追うのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから整えるのがおすすめです。