Notion の通信はなぜ「Notion 本体＋AWS」に分散しやすいか

Notion の Web 版・デスクトップ版（Electron 系含む）・モバイルは、画面を描画する notion.so 周辺の HTML／API だけにとどまりません。ブロックの本文・添付・埋め込み・サムネイルの取得では、オブジェクトが置かれている S3 バケット（*.amazonaws.com 等）や、その手前の CloudFront など CDN 上のホスト、社内利用では SAML／OIDC 連携用の IdP ドメインへも短時間に分散します。ここを雑に「Notion=notion.so だけ」扱いにすると、UI は開いても裏でファイル取得が 遅延・TLS タイムアウト し、表向きは「同期スピナーが終わらない」に見えます。Clash では、これらを同一の NOTION_AWS 向けストラテジへ束ね、ルール分流のベストプラクティス に従い GEOIP や大きい MATCH より前へ明示ルールを置くと、再現性が上がります。デスクトップ版は OS のトラフィック制御の影響を受けやすいため、TUN 対応クライアントの選定も合わせて見ておくと捗ります。

なお「amazonaws.com をまるごと」同一ポリシーにすると、他サービス向け S3 まで広く寄る可能性があります。実運用では接続ログに出た 実 FQDN から、Notion 更新時にだけ増えるホストを足していく方が安全です。モデル倉庫系の Hugging Face と CDN 分流 と同じく、S3／CDN という語だけでは中身のドメイン集合は一致しません。

典型症状とライブログでの切り分け

目に見えやすい例は次の通りです。(1) ページ一覧は出るのに、開いた瞬間のロード帯が終わらない。(2) 表やデータベースは見えるのに、画像・添付・カバー画像だけ出ない。(3) デスクトップとブラウザで「最終更新」表示が食い違い、同期の競合警告が出る。(4) 一時的に「オフライン表示」のまま戻らない。ブラウザ間で差が出るときは拡張ブロッカーとブラウザのセキュア DNS（DoH）を疑い、失敗行の SNI をメモに残すと、後からルールへ落とし込みやすいです。

ℹ 観測のコツ：同期が詰まった数秒前後のログを抜き、(a) notion 名義の API／WS 相当、(b) S3 取得（PUT／GET 相当の接続先）、(c) CloudFront 上の汎用ホスト、(d) 社内 IdP ／ SSO 用ドメイン、に大ざっぱに分類します。接続前に落ちるなら SNI 不一致や DNS、握手後の停滞なら帯域とノード品質、と切り分け、上記 TLS 記事 の表と照合してください。

notion.so／Workspace API・リアルタイム層

まず DOMAIN-SUFFIX,notion.so、公開ページや旧来の notion.site 系が絡むなら併せて、同一の NOTION_AWS ポリシーに載せるのが出発点です。エンタープライズのワークスペースや地域プリフィックス付きの API 名が増える事情は、固定リスト一発より手元のログ追記が本番的です。ルールの粒度が細かすぎて www だけ拾い、API 用サブドメインを漏らす、という形は特に陥りやすいので、サフィックス系で広めに当て、必要なら除外で絞る方が扱いやすいことが多いです。ブロック用ルールセットで解析ドメインを REJECT しすぎていないかも、ルールの上から順に点検します。

S3・CloudFront などファイル／CDN 系の束ね方

Notion 内の大きなアセットは、多くの場合 AWS 上の保存先＋配信層へ向かいます。接続先が s3. プレフィックス付きのリージョン FQDN や、CloudFront の *.cloudfront.net、あるいは S3 向け仮想ホスト型の *.s3.*.amazonaws.com などに分かれると、API だけ速い出口・ファイルだけ別の遅延ノードになり、体感では「永遠に回る」に近づきます。実際にログへ出た AWS 名を、Notion 利用時刻と突き合わせて NOTION_AWS へ足してください。amazonaws.com 全体を一括は他プロダクトと衝突しやすい点には注意し、GEOSITE 等の汎用ブロック条項が先に当たっていないかも確認します。LAN 内共有や別マシンからの同時接続の話に進む前に、LAN 共有と bind の内容と混同しないよう、主題を「外へ出る出口の一貫性」に置いてください。

ルール例：NOTION_AWS 用ポリシーへ集約する

狭い DOMAIN や Notion＋AWS 用の rule-providers を、巨大な GEOIP や汎用ストリーミング／一般 AI 向けルール集合より手前へ。グループ名 NOTION_AWS_STABLE には、遅延と地域がワークスペース方針と揃いやすいノード（もしくは契約上の DIRECT）を割り当ててください。以下は例示であり、本番前に接続ログで必ず検証してください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Notion + observed AWS endpoints into ONE policy; place BEFORE wide MATCH/GEOIP
rules:
  - DOMAIN-SUFFIX,notion.so,NOTION_AWS_STABLE
  - DOMAIN-SUFFIX,notion.site,NOTION_AWS_STABLE
  - DOMAIN-SUFFIX,notion.com,NOTION_AWS_STABLE
  - DOMAIN-SUFFIX,amazonaws.com,NOTION_AWS_STABLE
  - DOMAIN-SUFFIX,cloudfront.net,NOTION_AWS_STABLE
  - DOMAIN-SUFFIX,aws.amazon.com,NOTION_AWS_STABLE
  - MATCH,PROXY_OR_DEFAULT

amazonaws.com 一括の是非は、手元の他アプリ衝突で決めてください。狭めたい場合はログに出た 接続元プロセス＝Notion 時の FQDN だけ残す、あるいは process-name 系（Windows 等）を併用する方法もあります。ルールプロバイダの更新で REJECT が先に刺さると症状が戻るため、ベストプラクティスの順序意識を前提に、定期棚卸しをお勧めします。

他 SaaS 向けルールセットとの棲み分け

当サイトでは Perplexity や学術、Spotify など、別ドメイン集合向けの記事が大量にあります。それら用に整えた束を、Notion 向けの「NOTION_AWS」に差し替えないでください。逆に、ストリーミング記事で学んだ 「本体系と CDN を同じ出口へ」 という発想だけは活かせます。AI 専用の Anthropic 束とホスト名は重なりません。

システムプロキシ・TUN とデスクトップ Notion

ブラウザはシステムプロキシを通しやすい一方、Notion デスクトップは同じ口を使わないことがあります。表向きのプロキシ設定が効いていても、裏の取得が別径路、という切り分けは TUN モードの深掘り で整理した、カーネル近傍のトラフィック扱いと合わせて読むと早いです。macOS では TUN 周りの権限表示や他 VPN との優先度も影響するため、必要なら macOS TUN 記事も参照してください。購読取得だけ不安定なチェーンにルール更新を乗せると、昨日まで通っていた状態に戻りづらくなるので、更新系の DIRECT 確保は別途意識します。

DNS、fake-ip、ブラウザ DoH のズレ

fake-ip とブラウザの DoH が二重だと、ルールが想定する名前解決と実接続先が食い違い、同期中だけ証明書やホスト名が不自然に見えることがあります。fake-ip-filter や nameserver-policy の整理手順は Clash Meta の DNS 記事にまとまっています。CloudFront 経由の CNAME 連鎖で、一瞬だけ別ドメインに見えるホストが出る点には、ログの FQDN をそのまま採用するのが安全です。IPv4／IPv6 の挙動差で「片方だけ直進」が起きる場合は、IPv6 二重スタックの整理も併せて当たりを付けます。

⚠ コンプライアンス：Notion の利用規約、職場のセキュリティ方針、テナントで許可された通信経路を遵守してください。本稿は許可された環境で「出口の一貫性」を高める手順の整理であり、未承認の境界回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash 経由の Notion 利用が方針上許可されているかを確認する。
  2. 失敗直前の FQDN を列挙し、Notion 本体 API／S3・CDN／IdP の層に分ける。
  3. NOTION_AWS 束が MATCH より前で一貫し、ブロック系ルールと衝突していないか確認する。
  4. ブラウザのみと TUN 有りで A/B 比較し、デスクトップ取りこぼしの有無を切り分ける。
  5. Clash DNS／fake-ip とブラウザ DoH の二重構成を解消し、DNS 設定を一か所の前提に揃える。
  6. ルールと購読の更新取得が、不安定なプロキシチェーンに入っていないか確認する。

数分単位のログ断片を残しておくと、全体設定の入れ替えより早く、どの層の出口が揃っていないかに辿り着けます。

まとめ

Notion の「同期が終わらない」は、単一の notion.so の遅延だけに還元できないことが多いです。ワークスペースの API 層と、S3・CloudFront を含むファイル／CDN 層を、Clash で NOTION_AWS 向けポリシーへ束ね、システムプロキシと TUN のどちらがデスクトップの実流量を握っているか揃えれば、多くのケースは経路の部分ずれとして説明できます。DNS／fake-ip とブラウザ DoH の二重化を解き、他 SaaS 用のルールと混ぜないことが、長期運用で事故りにくいコツです。

→ 切り分け方針が固まったら、Clash を無料ダウンロードし、Notion 専用の小さなサブプロファイルで試し、接続ログに出た FQDN を都度足していくのが近道です。止まっていたスピナーを、本来の作業に戻せます。