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

2026：NotebookLM を Clash で——ウェブと音声 CDN の分流・DNS 実測

Google NotebookLMはソースを貼り付けた調査ノートから要約や質疑応答、多くの環境ではオーディオ概要（音声ガイド）まで出せるマルチモーダル寄りの製品で、ブラウザ上のnotebooklm.googleを窓口にしつつ、背後ではGoogle アカウント、API 風の通信、そして音声や大きな静的オブジェクト向けに別ホストへ伸びることが珍しくありません。本文はClashの分流ルールとDNSをセットで読み、Gemini 一般利用向けの稿（別稿）よりもNotebookLM 専用のホスト束に寄せた実測の型を整理します。ChatGPT／OpenAI 向け（参照）とも対象が異なります。ホスト名はサービス更新で増減し得るため、下記は出発点とし、常に自分の Rule ログを正としてください。

NotebookLM まわりで起きがちな「半分だけ成功」

相談で多いのは次のパターンです。(1) 一覧や編集 UI は動くが、オーディオ概要の生成だけ失敗する、(2) しばらく操作できるが突然認証に戻される、(3) テキスト応答は速いのに音声のバッファだけ延びる。いずれも単一の MATCH で一本化すると国内向けまで巻き込みやすく、逆にドメイン指定が狭すぎると 音声用の CDN やバックエンドだけ別経路に取り残される、というホスト集合のズレが典型原因です。VPNで端末全体をトンネル化すると症状は消えることもありますが、通勤中の国内サイトまで遠回りになりがちです。Rule型の Clash（Mihomo 系列）なら、NotebookLM 関連だけ選んだ出口へ寄せ、それ以外は従来どおり、という設計が現実的です。

用語は チュートリアル、ルール順序は カスタムルールで押さえておくと、この稿の「上に具体、下に広い束」を書きやすくなります。

proxy-groups に用途別グループを切る

購読には PROXY や ♻️ 自動選択 が既にあるはずですが、NotebookLM だけ手で差し替えたい場合は NotebookLMProxy のような名前付きグループ（select または url-test）を増やし、rules では実ノード名ではなくそのグループ名を指します。ネストの型は proxy-groups ガイドも参照してください。グループ名の綴りと rules の不一致は「足したのに効かない」第一候補です。

💡 ヒント 音声まわりだけ高帯域ノードにしたい場合でも、別グループを増やしてルール側で振り分ける方が、Global トグルで全体を振るより安全です。

ドメインの考え方：ウェブ入口・認証・API・メディア（音声）

ウェブ入口は notebooklm.google.com を中心に、画面枠まわりでは *.google.com や一部の *.gstatic.com が絡みます。Google アカウント系は accounts.google.com ほか OAuth 周辺でホストが増えやすく、ここが DIRECT とプロキシで割裂すると「突然ログアウト」「同意画面のループ」に見えがちです。バックエンド APIは環境次第で *.googleapis.com や clients6.google.com 系、play.google.com には触れないことも多いですが、ログに出た実名に合わせて足してください。

オーディオ概要や大きなプレビューでは、ブラウザの開発者ツール／Clash のコネクションログに googleusercontent.com や storage.googleapis.com、時に lh3.googleusercontent.com などメディアっぽいホストが現れます。ここだけ別ポリシーに落ちていると「生成は始まるが再生が終わらない」になり得るため、音声を試す直前のログを一度スナップショットしてからルールを育てるのが確実です。Gemini 専用に広げた generativelanguage.googleapis.com 一括をそのまま流用すると影響範囲が広すぎることがあるため、NotebookLM ではまずログ→DOMAIN で狭める運用を推奨します。詳細は Gemini 向け稿と役割分担してください。

rules:
  # Examples only — replace NotebookLMProxy; extend from your live logs
  - DOMAIN-SUFFIX,notebooklm.google.com,NotebookLMProxy
  - DOMAIN-SUFFIX,accounts.google.com,NotebookLMProxy
  - DOMAIN-SUFFIX,ogs.google.com,NotebookLMProxy
  - DOMAIN-SUFFIX,googleusercontent.com,NotebookLMProxy
  - DOMAIN-SUFFIX,storage.googleapis.com,NotebookLMProxy
  # If logs show only specific API hosts, prefer DOMAIN over broad SUFFIX:
  # - DOMAIN,notebooklm.googleapis.com,NotebookLMProxy

googleusercontent.com や googleapis.com は他サービスとも共有されるため、副作用が出たらログで特定の FQDNに落として上へ寄せてください。DOMAIN-SUFFIX,.google.com のような巨大一括は国内判定と衝突しやすく、最後の手段に近いです。

DNS：fake-ip／DoH と「名前は引けているのに TCP が落ちる」

ルールの宛先が正しくても、DNS 応答が期待とズレると証明書エラーや無限ロードに見えます。Mihomo 系では dns の fake-ip／redir-host、nameserver-policy で Google ゾーンだけ別リゾルバ、といった調整ができますが、購読テンプレから大きく外すと切り分けが難しくなるので、まずはテンプレ既定で再現し、それでもダメなら一度に一項目変えるのが安全です。ブラウザ独自の Secure DNS と Clash の DNS が二重に効いているときは、比較のためブラウザ側を一時オフにするのも有効です。キャプチャ不能なアプリ寄りの挙動を疑う場合は TUN モードでコア側に寄せる検討もあります。

動作モードとログの読み方

日常は Rule。切り分けの短時間だけ Global にすると「ルール不足かノード品質か」を分けやすくなりますが、国内まで巻き込むため常時は非推奨です。Direct はベースライン計測用。NotebookLM だけおかしいときは Rule に戻し、該当ホストが意図したグループへマッチしているかをログで確認します。オーディオ試聴中に細いホスト名が増えないかを見ると、メディア束の抜けに気づきやすいです。トンネル型サービスとの違いは Clash と VPN の比較も参照してください。

⚠️ 注意 省電力や「常時 VPN」スロットの競合でクライアントが止まると、ルール以前の問題になります。OS 側の接続状況も併記してください。

実測ステップ（再現可能な順序）

  1. 1

    Baseline（Direct または Clash 停止）

    同じブラウザプロファイルで notebooklm.google を開き、オーディオ概要まで含めてエラーが再現するか記録します。再現しないならルール／DNS 側の寄与が薄い可能性があります。

  2. 2

    Rule に戻し、接続ログを空読みする

    ドキュメント読み込み・要約生成・オーディオ生成・再生の各フェーズで、どの FQDN に向かっているか、どのルール行にマッチしたかをメモします。ここにないホストを足すのが次の一手です。

  3. 3

    一行ずつ追加して再計測

    DOMAIN-SUFFIX や必要なら DOMAIN を追加し、同じ操作を繰り返します。一度に大量変更すると、どの変更が効いたか分からなくなります。順序がズレたらより具体な行を上へ移動します。

  4. 4

    DNS クエリと突き合わせ

    名前解決だけ妙なときはルールより先に DNS を疑います。クライアントの DNS ログや、一時的な詳細ログで 応答タイプ（実 IP／fake-ip）が期待と合うかを見ます。

検索で拾ったドメインリストは参考程度に留め、自分の環境のログで育てたリストが保守に耐えます。2026 年以降 UI や*.googleapis.com の実名が増えても同じ手順で追従できます。

よくある質問

Gemini 向けのルールをそのまま流用してよいか

入口は近い一方で、NotebookLM のメディア／ストレージ系が不足しがちです。Gemini 稿を土台にしつつ、本稿の音声・CDN 束をログで補完するイメージです。

職場・学校の端末では？

プロキシ迂回や DNS 変更はポリシー違反になる場合があります。技術的に可能でも、組織の規程を優先してください。

ルールは正しいのに遅いだけのとき

選択中ノードの遅延・損失が大きいと体感は変わりません。url-test の間隔や別出口の検討が必要です。

まとめ

Google NotebookLMはnotebooklm.googleを表にしつつ、Google アカウント・API 風ホスト・音声やメディア向け CDNまで分岐しやすい製品です。Clashでは用途別の proxy-groups と順序の整理された分流、それから DNS をセットで扱い、Rule ログを正に育てると「画面は動くが音声だけ」といった中途半端な状態をかなり減らせます。全トンネル VPN に頼らず、用途単位で出口を読み分けたい場合に向きます。

クライアントは 本サイトのダウンロードページから揃えると、記事間の対応も追いやすく、ログベースの運用に戻りやすいです。ソース参照は公開リポジトリでも構いませんが、入手は本站を第一にしてください。

→ NotebookLM 向け分流を試す——Clash を無料ダウンロード