Notion がずっと「同期中」？ワークスペースが開けない？Clash（Mihomo）で Notion 本体・API・静的／CDN ドメインを分けて束ねる実測手順（Windows・2026）

1. 検索意図：Notion 同期失敗の「外側」と「中身」

本稿の想定読者は、Notion 同期失敗やローディングの固定を、いちど再現可能な手順で直したい方です。切り分けの第一歩は、症状が アプリ全体の遅さ（往復遅延・帯域）なのか、特定ホストだけ別経路に落ちているのか、です。全体が重いなら、プロキシノードの品質や混雑、あるいは社内帯域も疑います。一方で、左サイドバーは同期完了なのに本文ブロックだけ古い、画像や埋め込みだけ欠ける、といった層状の不整合は、Clash 分流のルール順と DNS、そして Windows 側のトラフィック取りこぼし（プロキシ非対応プロセス、別 VPN との併用）を疑う価値が高いです。

購読の骨格をまだ把握していない場合は、サブスクリプション取り込みの解説で基本形を固めてから戻ると、以降の「自作ルールをどこに挿すか」が素早く決まります。

2. Notion の通信を「面」に分けて眺める

以下は考え方の区分であり、固定のホスト名リストではありません。実装・リージョン・アカウント種別（個人・チーム）で FQDN は変化します。ログで自環境用の表を作り直す前提で読んでください。

同じ企業内でも「ブラウザは企業プロファイル経由、Notion デスクトップは別ユーザー権限」といった二重構造に寄与すると、見かけ上は一つの OS なのに出口策略が違うことになりがちです。

3. M365／Teams 既稿・Figma 既稿との読み分け

Teams と Microsoft 365 の記事では、会議系と O365 認証、Teams CDN の横断に焦点を当てています。Figma では共編集と WebSocket、キャンバス向け CDN を扱いました。本稿の Notion 代理向け手順は、コラボツール群の一つとして同じ土俵の悩み（スピナー、添付、リアルタイム性）を共有しますが、対象 FQDN の集合は重ならない前提です。症状が似ていても ログのホストで束ね直してください。Reddit や Spotify の 「アプリ＋CDN」型の記事の切り方も思考の補助線になります。

4. Windows 固有：デスクトップ版とシステムプロキシ

Windows では、ブラウザはシステムプロキシに従いやすい一方、一部アプリは独自の接続方式を使います。Clash 側をシステムプロキシにしているときにだけ Notion デスクトップの一部通信が抜け、TUN モードに切り替えると揃う、という観測はよく出ます。逆に、企業の別 VPN やセキュリティ製品のフィルタがルーティング層に座っていると、TUN でも奪い合いが起きるので、有効化のたびに「Notion 関連のホストが同じ出口に揃ったか」を接続ビューで見直してください。UWP ループバック等の特殊例は、必要に応じ Windows／Microsoft Store 周辺の稿を参照しつつ、本稿では汎用の考え方に留めます。

5. ログ収集：再現手順をシナリオ分けする

1. Clash を起動し、システムプロキシかTUNのどちらを主に使うかを一つに決め、併用中の他 VPN は可能ならオフにする。
2. Notion Web とデスクトップのどちらで症状が出るかを分け、それぞれで同期・ページ遷移・チーム空間移動を行い、接続ビューで同刻付近の FQDN を控える。
3. 特に、失敗し続けているサフィックス（notion.so 以外のロングテール）を箇条書きにする。購読ルール内の広い DIRECT に吸われていないかを、命中した策略名で確認する。
4. 同じ操作を、出口ノードを一時的に切り替えた場合も再現するか比較し、遅延型と経路分裂型のどちらに近いか切り分ける。

6. 短い検証：curl やクライアント表示で出口を揃えたか見る

ターミナルから curl -v を使う場合は、同じ Windows 上で Notion 実運用に使っている Clash 出口と、環境変数や別クライアントの上書きが食い違っていないかに注意します。企業用 PAC ファイルが、特定ゾーンだけゲートウェイに送っているケースもあります。検証は短時間に留め、各サービスの利用規約と社内方針を守ってください。TLS 層のエラーコードと、Clash ログの connection reset や timeout を対応づけると、DNS 失敗と出口拒否の区別に役立ちます。

7. DNS 方針：fake-ip と「名前と実体」のズレ

fake-ip はルール照合を速めますが、クライアントが解いた名前と、実接続の宛先解決のすり合わせが崩れると、上層の UI は一見正常でも下層の取得だけが回り続け、Notion 同期が終わらないように見えます。頻出ゾーンに nameserver-policy 的な扱い（実装名は利用中のコアのドキュメントに従う）を寄せ、DoH と通常 UDP の二系統で結果が食い違わないかを確認する、といったDNS 切り分けを、YAML のルール編集と同列の作業にしてください。フィールド名は Mihomo／Clash Meta のバージョン差があるため、手元の辞書に合わせます。

8. 推奨の切り分け順（チェックリスト）

1. Clash の稼働と、Windows が指している代理設定（手動・PAC）を一致させる。他 VPN の共存を一時的に外して再現性を比較する。
2. 接続ログで Notion 関連 FQDN が、意図したポリシー（例：PROXY グループ）に揃っているか。誤った DIRECT が上書きに負けていないか、ルール列の上から順に追う。
3. DNS モード、fake-ip、redir-host 等の組み合わせを点検し、必要なら Notion 系サフィックスだけ実アドレス解決に寄せる。
4. notion.so 本体と、静的・API・Notion CDN らしきホストを、DOMAIN-SUFFIX 等でより具体的に上段に置き、購読内の広い直結行より前に来るよう並べ替える。
5. 最後にノード遅延を疑う。改善が乏しい場合は、長距離回線向けの別グループや、帯域の大きいタスク（添付一括）の時間帯を変えて比較する。

一般的な起動失敗は 汎用トラブルシュートに回し、本稿はドメイン分裂に絞ります。LAN 内の他端末へ流す場合の注意は LAN プロキシの記事に譲ります。

9. 分流ルールの考え方（記述例は置き換え前提）

以下は 例示 です。実ホスト名は必ず自分の接続ログに合わせて置き換え、グループ名は proxy-groups の定義に合わせてください。購読内に「大きい DIRECT」が先に当たると、意図せず国内直結に落ちるホストが紛れ込みます。より限定的なサフィックス行を上に積み上げるのが実務的です。

# Example only — replace with FQDNs from your own Clash logs
rules:
  - DOMAIN-SUFFIX,notion.so,PROXY
  - DOMAIN-SUFFIX,notion.site,PROXY
  - DOMAIN-KEYWORD,notion,PROXY
  - DOMAIN-SUFFIX,amazonaws.com,DIRECT
  - MATCH,PROXY

上の例で amazonaws.com を直結にしている行は、実際のログで Notion 資産がどの S3 系に出ているかで真偽が変わるため、コピー禁止の定番ルールと勘違いしないでください。多くの環境では、Notion 用アセットが第三者 CDN に寄っている場合と、自社境界でブロックされやすいホストが併存します。ログ照合が唯一の正解です。API 専用グループを PROXY_API などに分け、障害時に「UI は開くが同期だけ失敗」といった切り分けをしやすくする手もあります。

10. システムプロキシと TUN

システムプロキシは導入が容易ですが、プロキシ非対応の通信や、別製品の仮想 NIC と競合すると抜け道が残ります。TUN は OS のルーティング層で取り込み、一貫性は上がりますが、権限や他 VPN との優先度の調整が必要です。有効化の手順は TUN モードの解説を参照し、切り替え前後で Notion 関連 FQDN の出口が一列に揃ったか接続ビューで確かめてください。

11. まとめ：証拠ベースで Notion 本体と Notion CDN を束ねる

Notion 同期が止まる問題は、単一の設定ミスよりも、全量出口の遅延、ルールと DNS、Windows 側の取りこぼしが重なり合って起こりがちです。本稿の順でログを揃えれば、「とりあえず出口だけ替える」より再現性のある改善に寄せやすくなります。購読に頼り切らず、ホスト表を自分の環境で更新する習慣を持てば、Notion 代理運用の保守も長く続きます。

接続ビューとルールを GUI で扱いやすいクライアントを使うと、Clash 分流の試行錯誤の負荷が下がります。他製品比較で迷う場合は、策の一覧性とコア版の食い違いが少ないものほど、マルチドメイン向けの運用に向く印象です。安定した始め方をしたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める