NotebookLM in 2026: Clash Split Rules for Web and Audio CDN (Tested)

What “NotebookLM is broken” usually means

NotebookLM failures rarely arrive as a polite single error code. Users describe clusters of symptoms that share one trait: partial connectivity. The marketing shell loads because HTML and a handful of scripts succeeded, then long-lived operations—upload processing, retrieval-augmented answers, sharing dialogs, or Audio Overview playback—fail when a later connection rides the wrong outbound, resolves through the wrong DNS path, or gets carved apart by an overly broad DIRECT slice intended for “China domestic” traffic.

Three patterns dominate support threads and router forums in 2026. First, authentication drift: Google identity flows bounce across several related hostnames; proxy only one leg and cookies or OAuth-style hops break in subtle ways. Second, API skew: batchexecute-style POST traffic and REST-shaped calls on *.googleapis.com must share policy with the web origin that initiated them; mismatched paths yield CSRF-like stalls or empty JSON wrappers even though TLS succeeds. Third, media skew: audio summaries are not philosophical “chat tokens”; they behave like downloads—large bodies, range requests, occasional redirects—so latency-sensitive proxy groups and naive domain exceptions interact badly. Treat NotebookLM as a bundle, not a single SNI.

Why this is not only a Gemini routing article

NotebookLM overlaps Google’s wider AI surface—many teams reuse shared edge caches, common identity plumbing, and similar telemetry—but the hostname graph you must satisfy for notebooklm.google is not identical to the shortest path that keeps Gemini chat responsive in a generic tab. Gemini-focused guides emphasize browser streams and general Google properties; NotebookLM adds notebook persistence flows, Labs-flavored endpoints, and Audio Overview delivery shapes that show up as distinct rows in your connection log.

Readers who already stabilized Gemini using our Gemini rules walkthrough should treat that profile as a starting point, then run the NotebookLM-specific capture pass below. Copy-pasting Gemini YAML without validating NotebookLM hostnames is how you end up with “Gemini works, NotebookLM spins”—exactly the regression we avoid by splitting product guides rather than merging them into one undifferentiated Google blob.

When Clash cannot fix the issue

No proxy replaces eligibility. Workspace administrators can disable labs features; consumer accounts hit availability and policy gates; enterprise tenants route through Cloud IAM boundaries that your laptop cannot rewrite. If every hostname in your capture already hits the intended outbound and TLS handshakes succeed—yet the application still refuses—you are likely facing account or region constraints, not split routing.

Corporate devices sometimes forbid split tunneling outright. Campus networks inject HTTP inspection that breaks HTTP/2 multiplexing in ways that resemble proxy failures. In those cases, Clash tuning is the wrong lever; policy and network design come first. When you do control the stack, Clash shines because it makes inconsistent paths visible: identical symptoms become differentiable once logs show whether failures correlate with DNS, SNI, or uplink congestion.

Step 0: reproduce and log hostnames

Open NotebookLM in a clean browser profile, reproduce the failure once, then freeze the test: same notebook, same upload size class, same Audio Overview generation if that is what breaks. Parallel changes—to DNS, rules, and proxy nodes—destroy causality.

Collect hostnames from two places that should agree. Browser DevTools Network shows polite labels and initiator chains; your core’s connection log shows what actually left the machine after fake-ip mapping and rule ordering. Export or screenshot the highest-signal rows: document requests, XHR/fetch, websocket upgrades, and large media transfers. If Audio Overview fails, sort by size or filter by media; the culprit is rarely the first HTML document.

Tag each hostname into buckets you will later encode as YAML: shell origin (notebooklm.google and any sibling you observe), identity (accounts.google.com and related), static (*.gstatic.com), APIs (specific *.googleapis.com subdomains your capture proves), and storage or media (*.googleusercontent.com patterns or Google Cloud Storage fronts if your trace shows them). Hyphenated guesses without evidence belong in a scratchpad, not production YAML.

Step 1: confirm capture mode

NotebookLM is browser-first for most readers. Decide whether your truth path is system proxy, TUN, or a hybrid where only some browsers honor environment variables. Mixed modes explain mysterious “works in Firefox, fails in Chrome” reports when only one browser picks up the dispatcher.

Validate capture independently of Google: hit a known test endpoint through the same interface NotebookLM uses, then toggle policy minimally and repeat. Our Windows-first client setup remains a practical baseline when you want a reproducible mixed-port configuration before layering AI-specific rules. On Linux desktops, stabilize who owns port 53 before blaming rules—our systemd-resolved-oriented DNS article walks through the stub resolver maze that otherwise masquerades as “Google is down.”

Step 2: align DNS, fake-ip, and dual-stack

fake-ip remains the default enhanced mode for disciplined split routing because it lets Clash steer flows based on domain knowledge captured at lookup time. It also punishes misconfiguration loudly: if OS DNS bypasses the core, domain matchers never see the names you think they see. Disable competing browser secure DNS while debugging; re-enable only after end-to-end passes.

Pick upstream resolvers that behave consistently on your network—some public DoH endpoints rate-limit or geo-resolve differently than ISP DNS, which shifts googleapis fronting in ways that feel like product bugs. Once lookups stabilize, re-run the NotebookLM capture and confirm that suspicious flows still resolve inside Clash’s DNS pipeline rather than leaking stub answers.

Dual-stack realities matter: if IPv6 prefers a path your rules never classify, you observe intermittent stalls that correlate with AAAA winners. You need not disable IPv6 globally—often a poor trade—but you must know whether your chosen capture mode actually intercepts the winning family. Logs should show coherent SNIs regardless of address family.

Step 3: rule order—NotebookLM bucket before MATCH

Clash is honest about precedence: the first winning rule owns the flow. Anti-patterns that trip NotebookLM readers include ultra-wide DIRECT slices placed above product buckets, “bypass China” lines that classify Google edges inconsistently, and DOMAIN-KEYWORD shortcuts that look clever until they collide with unrelated brands.

Build a dedicated outbound group—call it AI-GOOGLE-NOTEBOOKLM or similar—and route your validated hostname list there ahead of generic finals. Keep mainland bypass logic explicit where your geography requires it; see GEOIP CN bypass discipline for ordering inspiration that remains orthogonal to vendor-specific AI buckets.

After edits, change only one variable at a time: DNS upstream, rule order, or proxy node. Three-way diffs guarantee confusion.

Hostname hypotheses to validate in your logs

Use this list as a checklist of candidates, not scripture. Google rotates fronts; enterprise tenants add Cloud endpoints. Your capture wins.

• Product shell — notebooklm.google as the visible origin; confirm whether your resolver expands related names or ancillary hosts under the same brand.
• Identity — accounts.google.com, oauth2.googleapis.com, and siblings your login funnel actually touches.
• Static bundles — *.gstatic.com for JavaScript and style payloads that must match the shell version.
• API surfaces — narrowed *.googleapis.com entries tied to notebook operations; enterprise documentation references Discovery-style hosts such as *-discoveryengine.googleapis.com patterns—verify project and region strings against your admin console, never cargo-cult them from forums.
• Large payloads — *.googleusercontent.com or storage fronts when traces show audio bytes or attachment-like downloads.

If you embed assets from Drive or other Google apps inside notebooks, expect cross-talk: those hostnames belong in the same outbound bucket during the session even though they are not “NotebookLM-exclusive.”

YAML fragment: illustrative NotebookLM group

The snippet below is intentionally conservative: it demonstrates shape—narrow suffix lines tied to a dedicated proxy group placed above finals—not a universal subscription you should paste without edits. Replace AI-GOOGLE-NOTEBOOKLM with your real group name, merge duplicates, and comment anything your capture does not prove.

# Illustrative only — validate every DOMAIN-SUFFIX against YOUR logs
rules:
  - DOMAIN-SUFFIX,notebooklm.google,AI-GOOGLE-NOTEBOOKLM
  - DOMAIN-SUFFIX,accounts.google.com,AI-GOOGLE-NOTEBOOKLM
  - DOMAIN-SUFFIX,googleusercontent.com,AI-GOOGLE-NOTEBOOKLM
  - DOMAIN-SUFFIX,gstatic.com,AI-GOOGLE-NOTEBOOKLM
  - DOMAIN-SUFFIX,googleapis.com,AI-GOOGLE-NOTEBOOKLM
  # Optional: split googleapis.com into observed subdomains if you must keep YouTube or unrelated APIs DIRECT
  # - DOMAIN-SUFFIX,discoveryengine.googleapis.com,AI-GOOGLE-NOTEBOOKLM
  - MATCH,DEFAULT

Blanket googleapis.com routing is powerful and blunt—fine for dedicated AI workstations, risky on shared machines where Mobile backends should remain domestic. Prefer narrowing once your trace stabilizes. For maintenance hygiene, graduate repeated lines into a RULE-SET referenced above your finals, following the workflow in our custom rules tutorial.

Audio Overview and fat media edges

Audio Overview is where “mostly works” profiles die. The UI may show a playful waveform while the browser waits on a slow segment hidden behind a hostname your GEOIP slice declared DIRECT. Unlike conversational tokens that trickle, summaries arrive as bursty downloads—TCP windows, bufferbloat, and proxy uplinks matter.

Debugging starts with DevTools: identify whether audio rides same-origin fetches (harder to spot as “CDN”) or crosses onto storage-like hosts. Map those SNIs into the same outbound as your notebook shell unless measurement proves locality wins—Google often optimizes locality automatically, but your split policy can veto that optimization silently.

If playback stutters only on Wi‑Fi but not Ethernet, suspect plain congestion before YAML. If Ethernet fails consistently, elevate proxy latency measurements: some nodes rate-limit long bodies even when short chats feel instant. Switch nodes only after logs prove TLS and rule hits are correct; otherwise you chase ghosts.

NotebookLM Enterprise on Google Cloud

Administrators enabling NotebookLM through Google Cloud should expect additional project-scoped endpoints on googleapis.com, IAM-aware redirects, and organization policies that restrict egress. Consumer YAML rarely drops in verbatim. Treat enterprise captures like internal documentation: record literal hostnames, regions, and VPC Service Controls implications; pair networking changes with Cloud Audit logs rather than guesswork.

Readers comparing against consumer NotebookLM should remember split routing cannot bypass contractual boundaries—if Cloud denies an API call, Clash will faithfully proxy the denial.

Symptom map

What you see	First checks
Shell renders; sign-in loops	Identity hostnames share outbound with shell; disable browser secure DNS during capture
Notebook queries hang mid-answer	googleapis subdomains in logs—confirm fake-ip path and rule hit order ahead of MATCH
Audio Overview never starts	Large transfers filtered in DevTools; storage or content hosts not stranded on DIRECT
Flaky only on one browser	Capture mode per browser; extensions altering DNS or QUIC

Privacy, terms, and downloads

Routing changes path selection; it does not replace compliance with Google’s terms, organizational acceptable-use policies, or regional regulation. If split tunneling violates workplace rules, stop—visibility is not permission.

Prefer this site’s installer guidance for Clash-class clients: upstream repositories remain invaluable for source and issues, but packaging choices belong on vendor-approved download surfaces so checksum expectations stay coherent.

Putting it together

Stable NotebookLM access with Clash in 2026 rewards the same discipline as other multimodal AI surfaces: log hostnames before editing YAML, treat notebooklm.google as an anchor—not the entire graph—bundle APIs and fat audio edges with the shell policy when traces demand it, and align DNS enhanced modes with the capture path your OS actually uses. Compared with generic “proxy everything” toggles, targeted split lists keep domestic traffic sane, make regressions traceable when Google shifts fronts, and isolate NotebookLM from unrelated Gemini experiments when you deliberately separate guides.

For parallel reading on Google’s broader AI web stack, revisit Gemini rules and DNS setup; for contrast with a non-Google assistant path, skim Copilot identity routing. When you want a maintained client build aligned with modern cores, use this site’s download page—Download Clash for free and experience the difference.