2026 用 Clash 存取 NotebookLM：網頁與音訊 CDN 分流實測步驟
Google NotebookLM在社群討論裡常以「可做音訊概覽／多來源摘要」為賣點；以瀏覽器開notebooklm.google時，許多人遇到的不是整頁無法載入，而是對話區正常、播放器或長音檔載入永遠轉圈——這多半不是「單一 Gemini 網頁規則」能涵蓋的同一條出站鏈。NotebookLM會同時拉出帳號登入、靜態腳本（gstatic 等）、後端 API（多落在Google APIs／googleapis一族）與媒體下載／串流別名；任何一段落入錯誤的DIRECT／代理組或DNS 分裂，都會長得像節點品質問題。本篇用Clash（含Clash Meta／Mihomo常見語法）依本站其他 AI 題材同款流程：先連線日誌取證，再依「網頁殼／身分／資料面／播放器」四分桶分流規則，並收斂DNS（含fake-ip）。與站內 Google Gemini 專文刻意錯位：那裡偏生成式聊天與 generativelanguage 主機名；這裡鎖NotebookLM產品面與音訊概覽常見斷點。文內僅討論網路可達性與設定，使用服務須符合您所在地法規與 Google 條款。
先把症狀分桶：政策限制、瀏覽器快取，還是規則／DNS 失配？
在貼任何DOMAIN之前建議四桶分類。第一桶是產品或帳戶層限制（地區、Workspace 政策、年齡或教育版差異）；這類訊息若已明確寫在畫面上，Clash無法用規則「打開尚未開放的功能」。第二桶是瀏覽器外掛、隱私模式或舊 Service Worker 快取，表現像隨機壞；可用乾淨設定檔或無痕窗口先排除。第三桶才是本篇主軸：notebooklm.google殼出得來，但背景請求裡某段Google APIs或音訊檔下載主機被更早的GEOIP／MATCH送去非預期出站。第四桶是DNS回傳的位址、TLS 終端語意與你出口不符，播放器握著「可看的中繼別名」卻對不上通道。接下來請把NotebookLM、notebooklm.google、分流規則、DNS與fake-ip當成同一份實驗假設一起對齊，而不是只換節點盲測。
若你才開始用規則型代理，建議先看Clash 與 VPN 有什麼差別？確認「由上而下命中」的心智模型，再回到本文對症拆解。
和站內「Google Gemini」專文差在哪裡？
Google Gemini 教學偏重聊天介面與generativelanguage.googleapis.com等生成式對話鏈路；NotebookLM雖與Google 生態共用大量基礎設施（帳號、測試工具、資料面別名會重疊），但產品格局不同：筆記庫載入、blob／JSON API、來源抓取回呼與音訊輸出生成／下載在日誌上常自成一組主機序列。若在Gemini起手式上加兩條便以為涵蓋NotebookLM，最容易出現「文字可以談，音訊永遠 0％」這種分段成功。請把兩文的DOMAIN 起手式視為互不抄襲的清單：實際以你自己的連線記錄為準向外擴充。
第一步：用連線日誌還原四條線（網頁殼／身分／資料 API／媒體）
請在重現問題時開啟客戶端連線日誌，操作路徑建議覆蓋：①開啟notebooklm.google首屏；②完成 Google 帳號登入或切換；③建立或開啟筆記、觸發一次摘要；④點選音訊概覽（或等價音訊輸出）並讓播放器嘗試緩衝到失敗或成功為止。你通常會看到notebooklm.google本體、accounts.google.com與 OAuth 相關轉址、www.gstatic.com／fonts.gstatic.com等靜態資產、以及多個指向Google APIs子域的 HTTPS 呼叫；音訊段有時會出現下載型主機（例如帶簽章路徑的儲存／內容網域）或區域化別名，請勿假設與文字對話相同。
若日誌完全沒有動靜，先確認瀏覽器是否走系統 Proxy、或是否需啟用TUN；概念可讀TUN 模式深度解析。正確的產出物是你可逐條核對的 hostname 表，而不是論壇裡從未命中的複製貼上樹。
可把日誌主機名先粗分四類，後續補洞時對照下列矩陣（僅示意，請以實際日誌取代範例詞）：
# Hostname buckets from your connection log — replace with live names
| Role (examples) | Typical patterns (examples) |
| Web shell / product host | notebooklm.google, … |
| Account / OAuth | accounts.google.com, oauth flow hosts |
| Static / telemetry shell | gstatic, google.com, gtm, … |
| Data / media / blob / APIs | *.googleapis.com, storage-like hosts, … |第二步：可分桶的 YAML 起手式（務必依日誌擴充）
下方僅為教學起手式；Google 前端與 API 別名會隨版本調整，請務必以連線日誌補齊，並把條目放在會誤傷的寬規則（例如過早的GEOIP、MATCH）之前。NLM-OUT請改為你設定檔內既有的proxy-group名稱；群組觀念可讀Clash 代理群組指南。注意：googleapis.com非常寬，會把大量與NotebookLM無關的 Google API 一併送去同一出站；若你希望精細控制，請在日誌中挑實際命中的子域改寫成多條DOMAIN，並保留註解日期。
# Example starter — extend from your live connection log (2026-05)
rules:
- DOMAIN-SUFFIX,notebooklm.google,NLM-OUT
- DOMAIN-SUFFIX,accounts.google.com,NLM-OUT
- DOMAIN-SUFFIX,google.com,NLM-OUT
- DOMAIN-SUFFIX,gstatic.com,NLM-OUT
- DOMAIN-SUFFIX,googleapis.com,NLM-OUT
- DOMAIN-SUFFIX,googleusercontent.com,NLM-OUT
- DOMAIN-SUFFIX,googletagmanager.com,NLM-OUT
- DOMAIN-SUFFIX,googlevideo.com,NLM-OUT
- MATCH,Main說明：①gstatic.com與腳本載入失敗常導致「白屏或按鈕無反應」，不要只盯筆記主域。②googleusercontent.com與部分內容承載路徑在媒體或快取場景出現頻率不低；若日誌顯示更多儲存類後綴，請改以精準DOMAIN增列而非整段猜測。③googlevideo.com是否出現取決於實際打包與分發路徑；若你的日誌完全沒有命中，可刪去以免過寬。④嗅探與 SNI 不一致時，可延伸Clash Meta 嗅探與分流例外釐清。⑤需要條件式策略時，搭配自訂規則教學，仍以不重複其他 Google 產品專文的最小集合為原則。
第三步：為什麼「音訊概覽」特別像在考 CDN 分段？
音訊概覽這類輸出在產品行為上往往不是「網頁裡一串 WebSocket」就結束：產生完、授權下載／簽章 URL與實際讀檔串流或逐段請求可能對應不同主機前綴。對代理而言，任何一段若被規則提前送去DIRECT而其他段走NLM-OUT，瀏覽器端常只剩下「載入很慢」這種統計級症狀。做法仍是對播放器按下播放的 30 秒內完整截取日誌，按時間排序盯住新出現的最高頻主機名；那些才是你下一輪規則補洞的優先級。
若你已為Gemini寫過粗粒度DOMAIN-SUFFIX,google.com仍遇到NotebookLM音訊特例，請回到日誌比對：是否出現 Gemini 規則沒提到的子域、或播放器請求是否在另一個協定／埠上被規則遺漏。不要假設音訊永遠跟文字聊天同一出站。
第四步：規則順序與太早的 GEOIP／直連衝突
教學訂閱常有「國內或局域直連」或依GEOIP分流。若notebooklm.google或Google APIs／gstatic／內容承載別名在錯誤順序被送往DIRECT，可能出現首屏可看、對話區偶發報錯、或播放器永遠等不到完整音檔頭。請把日誌已驗證會出問題的主機名對應規則上移到誤傷條款之前，改後用同一瀏覽器設定檔開新工作階段再測，並清掉舊的媒體快取以免誤判。
第五步：DNS、fake-ip 與多層解析打架
當DNS回傳的位址、證書所屬域名與你出口地區三件事敘述不一致時，播放器特別敏感：它既需要正確時間戳簽章驗證，又依賴穩定的區塊順序載入。若啟用fake-ip，請收斂路由器、作業系統與 Clash 內建解析是否只剩單一路徑決策；測試期可暫時關掉第二套 DoH／第三方 DNS App。若你希望理解 Linux 桌面上stub 解析鏈與 Mihomo 互動，可對照Linux systemd-resolved 與 DNS 排查的思路：核心仍是單一事實來源，不是堆疊越多越好。
第六步：A／B 測——一次只動一個變因
在未對齊分流規則與DNS前，換十顆NLM-OUT節點常只能得到機率式的成功。建議固定同一份設定檔與時間窗口，每一輪只改一項：要嘛只前移兩條規則、要嘛只收斂解析、要嘛只切換少量同地區候選節點。上游品質問題可一併參考訂閱連結常見問題，避免把單次壅塞誤判成規則錯。
分步實測清單：建議按順序做
- 可觀測性：從載入notebooklm.google到點播音訊概覽，確認日誌出現連續出站記錄與對應策略組。
- 命中哪條規則：檢查是否被 GEOIP／FINAL／其他 AI 規則提前截走。
- 靜態資產：若版面殘缺或按鈕失效，優先補
gstatic與相關腳本載入域。 - 資料面／媒體面：播放器轉圈時，記錄當輪新增的下載類主機名並單獨增列規則。
- DNS 收斂：測試期只保留一條對外問路流程，關閉會覆寫的第二套DNS。
- 可維護性：把本輪補洞的
DOMAIN在 YAML 中以簡短英文註解標日期（code comment）。
合規、帳號安全與隱私提醒
代理會改變端對端路徑，中繼節點在技術上可能觀察到流量外型。請遵守所在地法律、組織資安政策與Google服務條款；對NotebookLM內容的著作權、來源合理使用與帳號風控，皆以官方政策為準。本文只協助你從Clash視角拆分分流規則與DNS配置，不提供規避身分或區域限制的建議。
常見問題
已經代理了notebooklm.google，為什麼音訊仍是 0％ 或一直 pending？
多數案例中，請求仍在Google APIs細分子域、googleusercontent／儲存類或下載別名上；請取出事當下日誌中播放器啟動後新出現的主機名並補規則。
整包*.googleapis.com送去代理會不會過寬？
會。起手式適合自查與對照；長期維護建議把日誌中確實出現的子域拆開寫在多條DOMAIN並註記首次觀察日期。
關掉fake-ip就一定能聽NotebookLM音檔嗎？
無絕對保證。重點是避免多套解析結果互相覆蓋；若在路由器、作業系統與 Clash三套並行問路，症狀常比開關單項更複雜。
總結來說，2026 年以Clash穩定使用Google NotebookLM／notebooklm.google並讓音訊概覽真正跑完整條載入鏈，核心是建立可追溯的連線證據鏈：先看見分段主機名，再用分流規則分桶網頁殼／身分／API／媒體，最後收斂DNS與fake-ip；並與Gemini 專文等站內 Google 題材保持域名清單獨立維護。若你希望用能清楚呈現規則命中、並對應現代 Mihomo／Meta 核心的客戶端驗證上述步驟，可先從本站取得安裝檔並照表操演——→ 立即免費下載 Clash，開啟流暢上網新體驗。