チュートリアル 2026-05-03 · 約 19 分

Notion ワークスペースが読み込みのまま？2026 年、Clash の分流で CDN と API を安定させる

Notion はブラウザ版とデスクトップアプリの両方があり、資料・議事録・データベースによるオフィス協業のハブになりやすい海外SaaSです。一方でユーザー検索にも多いように、サイドバーやページ本体は表示される一方で一覧がぐるぐる回ったまま同期や書き込み保存だけが失敗する、といった切り口の不具合はネットワーク層でのCDNとバックエンド APIの分流が食い違っているときに起きやすいパターンです。本稿では Clash（Clash Meta／Mihomo を想定）で *.notion.so や関連ホストを独立ポリシーグループに束ね、DNS・fake-ip・ノード選択をログで突き合わせながら一本化する手順と、メールや社内向けをDIRECT に残す典型を整理します。手順は雇用契約・情報セキュリティ規程・各国の法令・サービス約款の範囲で適用してください。

「ページが開けない」「ワークスペースのトップだけ白い」「サイドバーは出たがコンテンツが永遠に読み込み」「共有リンクは見えるが編集だけ保存できない」など協業ツール特有のフラストレーションが、そのまま検索クエリになります。このうちサービス側障害ログに当たらないときは、アプリ側の設定ではなくネットワークの出口と名前解決の組み合わせを疑う価値が高く、本稿ではその典型的なひとつの型として説明します。日本語環境だけでなくアメリカ西海岸やシンガポールのユーザーでも「海外エッジに近い出口が必要」の状況は似るため選択するノードの地理も含め検討材料になります。

ひとつの画面が複数の経路になる理由

Notion のようなモダン Web アプリでは、ユーザーが見える「ひとつの画面」でも裏側では複数種類のリクエストが走ります。HTML ベースのアプリペイン、アイコンやスクリプトを載せる静的資産のホスト群、データ取得・検索・共同編集のためのREST／GraphQL 風 API、そして状態を素早く流すためにWebSocket や長時間のHTTPS ストリームが混在することがあります。ここへプロキシの粗いフィルターやデフォルトだけの一覧ルールセットを適用すると、たとえば notion.so メインだけが安定グループに入って、実際には大量の転送が走るprod-files-secure 系などCDN 側の名前が広い MATCH ルールへ落ち、レイテンシやブロックリストの癖でだけ振る舞いが悪くなる、という状態が続きやすくなります。

  • 表層のアプリホスト：ワークスペースのハブとしての HTML／SPA 読み込み。
  • CDN 層：*.notion.so およびログに現れる関連サブドメイン（環境により変わる）。
  • データと同期層：一覧・インデックス更新・競合検知につながる API と長めのライブチャネル。

構成はFigma でキャンパス読み込み・CDN・WebSocket を別出口にしないという話であり、より「ドキュメント＋一覧中心」の性質になります。デザイン協業と Clash 分流の稿と思想は近く、読み替えだけで済む読者にも参照しやすいです。また Microsoft 側のセットと比較するなら Copilot・Office と Clash も並行読みになります。

開発者ツールで何を並べて見るか

Clash のログページとブラウザの Network を時間を合わせて眺めるのが最速です。XHR／Fetch で赤い項目があるか、サイズが読み込めないまま Pending のまま増え続けるホストがあるか、WS 接続だけがクローズされていないかを見ます。HTTP/2 を前提に複数ホストへの平行リクエストが走るサービスほど別出口に逃げやすく、画面上はサイドバーだけ更新されているのに本文が読み込めないようなねじれに見えやすくなります。デスクトップ版だけ症状が強いときは証明書とシステムプロキシとの二重化も疑ってください。

チェックポイント

速度テストで速いノードでも小さな往復と再接続に弱いと一覧の差分更新が途切れて見えます。ダウンロード帯域よりラウンドトリップの安定とログ上のフラップを優先して評価してください。

「Notion だけ安定出口」に束ねる分流

フル VPN 的に端末全体をトンネルすると、国内の会計クラウドや社内ポータルまで遠回りになることが多いです。よくある実務は、(1) ログに出た Notion 関連サフィックスを NOTION-STABLE のような専用 proxy-groups へ、(2) GEOIP や社内ドメインで国内向けを DIRECT、(3) 海外一般は別グループ、という上から細かい順にルールを置くことです。Clash Meta では DOMAIN-SUFFIX,notion.so,NOTION-STABLE を骨格にしながら、実際のセッションで追加されたホストを DOMAIN 行で足していくと保守しやすく、サービス側が新しい CDN エッジ名を増やしても追従しやすいです。

ポリシーと契約

通信経路の変更は組織のセキュリティ規程に抵触する場合があります。会社支給端末では IT 部門の承認を得てから試し、禁止されている場合は手順を適用しないでください。

ルール順と YAML の例（あくまで骨格）

以下は思考実験用のたたき台です。実ホスト名はブラウザと Clash のログで置き換え、環境と契約に合うノード名を入れてください。

# Illustrative — verify real hostnames in browser Network + Clash logs
proxy-groups:
  - name: NOTION-STABLE
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,notion.so,NOTION-STABLE
  - DOMAIN-SUFFIX,notion.site,NOTION-STABLE
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

notion.site は公開ページの閲覧で触れることがありますが必須ではありません。GEOIP,JP,DIRECT は日本拠点の例示です。MMDB の版や社内の定義に合わせ国コードを変えてください。リモート rule-providers をマージする場合、自作の NOTION-STABLE 行が広い最終ルールより上に残るか、インポート順で黙殺されていないかを必ず確認します。

ルールの型 向く場面 注意
DOMAIN-SUFFIX プロダクトの基準ゾーンがはっきりしている CDN が別名だと取りこぼす → ログで追記
DOMAIN 単発の API ホストだけ別名のとき 行が増えるのでコメントで理由を残す
PROCESS-NAME デスクトップ版だけ切り分けたい マルチプロセスと実ログで要検証

DNS と fake-ip を出口と一致させる

「タブを開いた瞬間だけ真っ白」「同期だけ途切れる」といった症状はルールより手前の DNS を疑うのが早いです。fake-ip を有効にしていると、ブラウザ拡張や別 DNS クライアントが実アドレスと見せかけアドレスを食い違わせて TLS 確認がザラつくことがあります。手順は DNS／fake-ip の稿に譲りますが変更は一度に一つだけで切り分けてください。また社内キャプティブDNSやフィルタ付きキャッシュが挟まっていると名前解決は成功ログでも実 TCP が別経路になり得るので注意します。

長めの HTTPS／WebSocket を同一ポリシーへ

共同編集は差分適用やカーソル位置のような短命リクエストと、低頻度だが状態を張り続ける接続がセットで動くことがあります。この長寿命チャネルだけが広い規則に落ちていると画面上は一覧が読めても自分の入力がサーバに載らないように見える状態になります。WebSocket と分流に関する稿の切り分けも参考にしてください。ブラウザでは広告ブロッカーなど拡張のないプロファイルでの再現確認が有効です。

ノード選択と url-test の間隔感

NOTION-STABLE グループにはレイテンシとジッターが読み書き体感に載りにくいサーバのみを並べます。url-test の interval を短くしすぎるとセッション中に出口が切り替わり同期がフラッシュしたように見える一方、長すぎると実際には落ちているノードに張り付くリスクがあります。ログのpolicy 列がどのアウトバウンドに張られているかを見ながらバランスを取ります。必要なら fallback 型と併せて復旧だけ速い別集合を試すなど自分のワークロードでの振る舞い優先です。

オフィスの国内トラフィックを DIRECT に残す

メール、国内ストレージ、社内チャットなどはすべてを同じ海外出口に載せる必然は薄いことが多く、むしろ固定 IP 許諾リストで社内サービスだけ弾く逆向き運用に干渉しやすいです。GEOIP と社内向け DOMAIN-SUFFIX を慎重に並べれば帯域のムダだけでなくセキュリティ監査側の視点でも説明がしやすくなります。リモート勤務だけで構成が単純な個人開発者とはレイテンシ要件の並び順が変わり得ます。

症状別の読みと切り分け

ワークスペース一覧がスピナーのまま

メインのアプリコードは読めている一方で一覧取得 API か静的アイコン群がタイムアウトしているときに見えやすく、Network で失敗状態のステータスまたは Pending のホストが手掛かりになります。そのサフィックスを NOTION-STABLE へログドリブンに追記します。

入力は見えるが保存や同期だけ失敗

PUT／PATCH 系がブロックされていないか、長寿命接続のみ別ポリシーに漏れているかを見ます。また競合状態の UI と誤認しやすいためオフライン表示が出ないかも併せて確認すると誤検知を減らせます。

ブラウザは正常でデスクトップだけ異常

証明書ストア読み込みやアプリ内プロキシと Clash が二重になっていませんか。両者を統一するかアプリのみシステムプロキシ準拠に落とします。

Windows／macOS での下地づくり

TUN とシステムプロキシの組み替えはプラットフォームで癖があります。Windows 側は Windows 向けセットアップで権限やモードを固めてから本章のホストリストを載せます。Mac では Clash Verge Rev の設定でローカルの整合を取ってから適用すると手戻りが減ります。

よくある質問

広告ブロックと相性が悪い気がする

一部リストは広告ではなく機能トラッキングと共用ドメインを同梱することがあり、その結果としてSaaS の一部サブパスだけ落ちる事例があります。拡張をオフにして再現確認しリストを調整してください。

企業 SSO のみログインできない

IdP とリダイレクトチェーンがNotion メインドメインと別運用のことがありログイン処理だけ規則から漏れます。そのドメインも同じグループへ含めるか、少なくとも同じレイテンシ帯へ寄せます。

iOS と比較して不安定になる

モバイルとデスクトップではTUN と証明書制約が異なります。iOS とサブスク・証明書の稿と症状を並べ読みすると差分説明が早いです。

手早いチェックリスト

  1. 開発者ツールと Clash ログで失敗または Pending が続くホスト名をリスト化する。
  2. それらを NOTION-STABLE に束ね、リモートルールより上位に並べられているか検証する。
  3. DNS・fake-ip・システム DNS の三点で解決結果に食い違いが無いか切り替えテストする。
  4. url-test の間隔やノード集合をログで読み、アイドルと編集中の両方で安定する構成に調整する。
  5. 会社 IP 許諾が絡む社内サービスは DIRECT と出口変化リスクが競合しないか確認する。

まとめ

2026 年も分散チームでのドキュメント・ナレッジのハブとしてNotionの需要は強く、海外CDN とバックエンド API が分散するためにブラウザ上のひとつの画面でも出口のねじれだけでワークスペース一覧がぐるぐる回り続けたり、同期や保存のみが失敗したりする観察が出ます。

こうしたとき、汎用の常時オン VPN ではドメインレベルの制御やログに基づく説明が難しくなりやすく、フルトンネルにするとむしろ社内システムの許諾 IP と衝突したり体感を逆に落としたりすることがあります。一方Clash（Meta／Mihomo など）はホスト単位で分流ルールやDNS、ノード選択を揃えた経路を再現できるため、「どの名前がどの出口に流れたか」をチームでも共有しやすく、アプリ開発者でない協業メンバーにも手順として渡しやすい利点があります。

ワークスペースが止まる症状はストレスだけでなくコストにも直結するので、自分の許諾環境では一度ログ駆動の切り分けを試したい方におすすめです。Clash を無料ダウンロードして、ログで経路と DNS を並べて確認することから始められます。

Notion のワークスペース読み込みを安定させる

CDN・API を同一ポリシーにまとめ、DNS とノードをログベースで揃える。

Clash をダウンロード