1 为何要把 NotebookLM 从「泛 Google」里拆出来讲
许多订阅规则已经内置「Google 直连」或「Google 走代理」的大类，但NotebookLM在 2026 年的实际体验里，仍经常出现「首页能开一半、资料一上传就断」「同一浏览器里 Gmail 正常、笔记本里 OAuth 反复跳转」这类局部故障。原因之一是产品入口并不总是你熟悉的 *.google.com 形态：notebooklm.google 这类位于 .google 顶级域下的主机名，若规则集更新滞后或本地手写规则只覆盖了 google.com，就会被错误地落到默认策略，表现为间歇性超时或 TLS 握手失败。
另一个原因是 NotebookLM 与文档解析、向量检索、账户会话强相关，后台会并行请求 googleapis.com、gstatic.com、googleusercontent.com 以及可能的实验性子域。任意一条链路被配成与你主站不一致的出口（例如主站走了低延迟节点，而静态资源误直连），前端就会表现为加载动画一直转、生成摘要按钮灰掉或报错文案含糊。把Clash 分流写成可验证的对象（固定策略组 + 日志可对主机名），比反复切换「全局规则」更能稳定复现问题。
若尚未安装图形客户端，可先前往本站下载页选择支持 Mihomo 内核与订阅管理的工具。站内《用 Clash 稳定访问 Gemini 2.5：Google AI Studio 分流规则》侧重 AI Studio 与 Gemini API，本文则聚焦 NotebookLM 的入口与笔记工作流，两者可共用底层 Google 策略组，但建议在规则顺序上显式点名 NotebookLM 相关主机，避免被泛规则「夹带」到意外出口。
2 与通用「Google 直连 / 代理」并存时要注意什么
实战配置里常见三类写法：订阅自带的 GEOSITE 或远程 Rule Provider 把 Google 标为直连；手工把 google.com 统一代理；以及按业务拆出 PROXY_GOOGLE 专用策略组。NotebookLM 是否稳定，往往不取决于「你选了哪一种哲学」，而取决于同一浏览器会话内所有相关主机是否落在同一种哲学上。若 accounts.google.com 走代理而部分 API 主机被更早的规则判为直连，就会出现登录态诡异、上传进度条卡住、或 WebSocket 长连接被中间设备干扰的症状。
Clash / Mihomo 的 rules: 列表按自上而下首次命中生效。与通用 Google 规则并存时，建议把更具体、与 NotebookLM 强相关的条目放在泛匹配之前，例如先写 DOMAIN-SUFFIX,google（覆盖 notebooklm.google）或等价规则集，再让后续的「谷歌大全」类规则接手其余子域。若你把 NotebookLM 单独绑到 PROXY_NOTEBOOK，而泛 Google 规则写在更前面且指向 DIRECT，则永远不会命中你的专用组——这不是内核 bug，而是规则优先级问题。
同理，若公司或校园网对特定 SNI 有审计，NotebookLM 的长连接可能比普通网页更敏感。此时「全 Google 直连」未必比「统一走可信代理」更稳。结论是先对齐策略，再谈快慢：同一产品的前端、鉴权、API、静态资源四类流量，宁可略宽地走同一策略组，也不要拆成四种互相打架的出口。
notebooklm、googleapis、accounts.google 三类前缀；若同一分钟内出现两种不同策略名，优先回头改规则顺序或合并策略组，而不是先换机场。
3 NotebookLM 相关域名与流量面（2026 实践向清单）
下列清单以「尽量不漏」为目标，实际主机名可能随 Google 迭代增减；以你浏览器开发者工具 Network 面板与 Clash 日志为准做增量维护。入口与主站：至少覆盖 notebooklm.google（以及若重定向涉及的 www.google.com、google.com 路径）。账户与 OAuth：accounts.google.com、oauth2.googleapis.com 等常见鉴权端点。API 与后端：googleapis.com 及其子域（NotebookLM 业务请求多落在此类主机上）。静态与附件：gstatic.com、googleusercontent.com，与上传 PDF或大文件时的分块上传相关。
若你同时使用 Drive 作为来源，可能额外命中 drive.google.com、docs.google.com 等；这与 NotebookLM 同属 Google 文档生态，通常并入同一 PROXY_GOOGLE 或你已有的 Google 策略组即可，避免 Drive 走代理而 NotebookLM 侧误直连导致「来源文档打不开」。使用社区 Rule Provider 时，选择维护积极的 Google 分类，并开启定期更新；自维护时优先用 DOMAIN-SUFFIX 明确后缀，减少误伤。
与站内 Gemini 专题相比，NotebookLM 更强调「多阶段任务」：选书、上传、索引、对话、导出摘要，任一阶段域名遗漏都会在 UI 上表现为不同按钮失灵。把域名当作产品生命周期来维护，而不是一次性抄一段 YAML，长期成本更低。
4 Clash / Mihomo 配置片段：DOMAIN-SUFFIX 与 RULE-SET
下面是一段示意性配置，演示如何将 NotebookLM 与常见 Google 后缀挂到 PROXY_GOOGLE。请与你现有的 proxy-groups 名称对齐，并与订阅规则合并时注意顺序靠前优先。若已使用远程规则集，可把重复的后缀删除，只保留日志里仍未命中的补缺行。
# Example only — merge with your profile; order matters
proxy-groups:
- name: PROXY_GOOGLE
type: select
proxies:
- AUTO-BEST
- DIRECT
rule-providers:
google:
type: http
behavior: classical
url: "https://example.com/rules/google.txt"
path: ./rules/google.yaml
interval: 86400
rules:
# NotebookLM entry on .google TLD
- DOMAIN-SUFFIX,google,PROXY_GOOGLE
- DOMAIN-SUFFIX,google.com,PROXY_GOOGLE
- DOMAIN-SUFFIX,googleapis.com,PROXY_GOOGLE
- DOMAIN-SUFFIX,gstatic.com,PROXY_GOOGLE
- DOMAIN-SUFFIX,googleusercontent.com,PROXY_GOOGLE
- RULE-SET,google,PROXY_GOOGLE
其中 DOMAIN-SUFFIX,google 用于匹配形如 notebooklm.google 的主机名（后缀为 google）。若你的规则集已包含等价条目，请勿重复堆砌，以免增加匹配开销。更系统的 DNS 与 FakeIP 设计，请参阅《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》。
DOMAIN-KEYWORD,notebooklm，但生产环境更推荐明确后缀与 Rule Provider，避免误匹配无关域名。
5 规则优先级：专用组、泛 Google 与最终 MATCH
推荐的分层思路是：第一层写产品敏感、易被泛规则误判的条目（如 .google TLD 上的入口、或日志里反复出现的独立主机）；第二层接订阅提供的 Google 规则集或 GEOSITE,google 类匹配；第三层才是地区、流媒体、广告拦截等业务规则。这样当你需要「只调 NotebookLM 的出口」时，可以只改 PROXY_GOOGLE 所选节点，而不触动整张表。
若你同时保留「中国大陆站点直连」与「Google 代理」，务必确认没有一条高优先级规则把某个 googleapis.com 子域错误直连。此类问题在 生成摘要或后台重建索引时最常暴露，因为前端会发起一批你平时浏览遇不到的 API 调用。用 Mihomo 的日志关键字搜索比凭感觉改规则更快。
对于团队环境，建议把 NotebookLM 相关规则放进可版本控制的片段文件，通过 rule-providers 或配置合并注入，而不是散落在多个 GUI 文本框里；否则同事复制你的订阅后，很容易出现「同一仓库、两种路由结果」的隐性差异。
6 常见现象：登录、上传 PDF、生成摘要失败怎么查
登录与 OAuth 循环
若页面反复跳回登录页或提示会话无效，先在 Clash 日志中确认 accounts.google.com 与当前 NotebookLM 页面主域是否命中同一策略组。混合出口会导致 Cookie 与安全令牌校验异常。其次检查浏览器是否启用「按站点分流」类扩展，它们可能绕过系统代理，使账户请求未进入 Clash。若使用多配置文件，确认当前启用的是包含 Google 规则的那份。
上传 PDF 或资料卡住
上传 PDF失败时，除文件大小与格式限制外，网络侧常见原因是：分块上传到 googleusercontent.com 或相关存储端点时，被错误直连或走了高丢包节点；或企业网络对上传流量限速。建议在日志中过滤上传阶段的 host，固定一个低延迟、稳定的节点复测。若仅大文件失败，还要排除本地杀软或 HTTPS 扫描对长连接的干扰。
生成摘要或对话无响应
此类功能依赖后端长耗时请求与可能的流式响应。若 googleapis.com 下某子域间歇性超时，界面往往只显示通用错误。处理方式包括：为 PROXY_GOOGLE 选择支持 HTTP/2 且稳定的线路；避免在同一策略组内频繁自动切换节点；以及在 DNS 侧排除污染与错误解析。若同一节点下 Gemini 或 Drive 正常而仅 NotebookLM 异常，仍应抓包看具体失败主机名，再补后缀或调整顺序，不要假设「Google 都通就等于 NotebookLM 一定通」。
7 TUN、系统代理与终端一致性
仅开系统代理时，浏览器通常能走 Clash，但桌面客户端、Office 插件或某些 Electron 应用可能仍直连。NotebookLM 虽主要是 Web 应用，若你从 Drive 拖入文档或使用浏览器以外的同步工具，就值得启用 TUN 做全栈一致。具体驱动与权限说明可参考《Clash Verge Rev TUN 模式完全指南》。
DNS 方面，FakeIP 与远程解析配置不当会导致「规则显示命中代理，实际连接却走错」的错觉。NotebookLM 一类富前端应用对 DNS 错误特别不友好，表现为资源 404 或无限重试。务必把 DoH、fallback 与 nameserver-policy 配成你可解释的一套，并在改 DNS 后重启客户端与浏览器。
2026 年主流 Mihomo 系客户端已能较好配合远程 Rule Provider 与订阅自动更新；仍建议每月抽查一次规则集版本与 Geo 数据，避免 Google 侧新增域名后长期未覆盖。站内《Clash Meta 手动更新 GeoIP 与 Geosite》提供了误判时的替换思路，可与本文搭配使用。
8 常见问题
- 已经写了 google.com，为什么 notebooklm.google 仍异常？后缀不同：
notebooklm.google不以google.com结尾，需要DOMAIN-SUFFIX,google或等价规则集条目。 - 与 Gemini / AI Studio 规则会冲突吗？不会天然冲突；两者可共用
PROXY_GOOGLE。注意不要把 NotebookLM 专用规则放在泛MATCH之后。 - 直连 Google 更快，为什么要走代理？视地区与线路而定；若直连不稳定，统一走稳定代理往往比「部分直连部分代理」更少诡异故障。
- 报错与账户地区或条款有关吗？有可能。网络层排错无果时，应核对 Google 账户状态、产品可用区域与服务条款；本文仅讨论客户端侧路由可达性。
9 总结
2026 年要在复杂网络环境下稳定使用 NotebookLM，关键是把 Google 生态里与笔记、鉴权、API、静态资源相关的域名，收敛到可预测的策略组中，并用日志验证规则优先级是否真如你所想。通过 DOMAIN-SUFFIX 显式覆盖 notebooklm.google 一类入口，再配合 Rule Provider 做持续更新，比单纯依赖模糊的「Google 规则」更少踩坑。登录异常优先查账户主机与产品主域是否同出口；上传 PDF与生成摘要失败则优先查存储与 API 子域是否被前置规则误伤。
相比其他同类工具，Clash 系在规则可读性、Mihomo 生态与客户端选择上的组合，对需要同时照顾浏览器、云文档与多款 Google AI 产品的用户往往更可控；把分流写清楚，比反复切换全局模式更能减少间歇性故障。
需要安装或升级客户端时，请使用本站下载页获取各平台安装包；开源仓库适合查阅协议与参与贡献，与日常安装包获取路径区分开，更符合安全与版本管理习惯。
