2026년 Google NotebookLM을 Clash로 쓰기: 웹·notebooklm.google·오디오 CDN·DNS 분류 실측

① Gemini 웹 튜토리얼과 무엇이 다른지 한 번에 잡기

같이 Google·생성형 AI 계열이라도 Gemini 중심 글은 보통 gemini.google.com·generativelanguage.googleapis.com 같은 축을 먼저 말합니다. NotebookLM은 제품 표면이 notebooklm.google 쪽에 가깝고, 소스 문서 처리·오디오 개요 생성 때문에 작업 시간이 긴 요청과 대용량 미디어 응답이 끼어듭니다. 그래서 「페이지는 열렸는데 버튼만 회전한다」·「목소리만 끊긴다」처럼 증상이 나뉘는 경우가 많습니다.

큰 그림은 Google Gemini·Clash 분류와 공유하지만, 규칙에 넣을 서픽스 묶음과 대역에 민감한 앱 행동은 다르게 잡는 편이 낫습니다. 이미 Gemini용으로 google.com 전체를 넓게 PROXY에 올려 둔 프로필이라면 NotebookLM도 같이 따라갈 가능성은 있지만, 반대로 좁게만 열어 둔 프로필에서는 빠진 호스트가 오디오나 백엔드에서 드러납니다.

② 증상을 세 가지 축으로 나누기

지원이나 셀프 점검에서 시간을 아끼려면 첫 메시지를 구체화하는 것이 좋습니다. 첫째, 웹 셸(목록·에디터 UI)은 뜨는데 분석/생성 버튼만 실패하면 API·웹소켓·긴 폴링 쪽 호스트가 DIRECT로 나가거나 반대로 잘못된 노드로만 가는 경우를 의심합니다. 둘째, UI는 정상인데 오디오 개요만 재생·다운로드가 안 되면 오디오 CDN·스토리지 계열이 규칙에서 빠졌거나, DNS 경로가 캐시와 어긋난 경우가 흔합니다. 셋째, 로그인 루프·쿠키 경고는 accounts.google.com·gstatic·브라우저 서드파티 쿠키 정책까지 같이 봐야 합니다.

한 번에 원인 후보를 열 개 적기보다, 위 세 축 중 어디에 가장 가까운지 먼저 고정하고 Clash 연결 기록에서 해당 시각 전후의 DOMAIN·CHAIN을 모으면 다음 단계가 빨라집니다.

③ 분류 후보: 웹 입구·API·정적·오디오·스토리지

구글 제품은 배포망이 자주 바뀝니다. 아래는 규칙 후보 목록이지 전체 고정 테이블이 아닙니다. 반드시 본인 환경의 로그로 덧대야 합니다.

• 제품 웹·앱 셸: notebooklm.google, notebooklm.google.com, 관련 *.google.com 하위 호스트(로그로 확인)
• 계정·인증: accounts.google.com, oauth 리다이렉트에 따른 ssl.gstatic.com 등
• 정적 자산: gstatic.com, googleusercontent.com, 프로필·아이콘·스크립트 번들
• Google API·백엔드: googleapis.com, *.googleapis.com — NotebookLM 관련 서비스 이름은 콘솔 네트워크 탭과 Clash 로그를 함께 보며 좁힙니다
• 미디어·스토리지 성격: storage.googleapis.com, *.googleusercontent.com의 긴 객체 URL — 오디오 개요 재생이 여기로 이어지는 사례가 있습니다

googleapis.com을 통째로 PROXY에 올리면 다른 구글 앱까지 함께 움직일 수 있습니다. 반대로 너무 쪼개면 빈 호스트가 생깁니다. 실무에서는 먼저 NotebookLM만 재현시키고, 로그에 반복되는 DOMAIN-SUFFIX부터 묶음으로 추가하는 방식이 덜 지저분합니다. 규칙 문법·순서 기본은 사용자 정의 규칙 튜토리얼과 동일합니다.

④ 오디오·CDN 구간이 왜 규칙에서 빠지기 쉬운지

텍스트 페이지는 수 KB 단위 요청이 많아도 끊어 전송해도 체감이 덜한 편입니다. 반면 오디오 개요는 수 분 길이의 스트림에 가까워 TCP 세션 유지·지연 변동·중간 프록시의 타임아웃에 더 민감합니다. 일부 노드는 짧은 웹 요청은 괜찮은데 긴 다운로드에서만 불안정해 보이기도 합니다. 또한 CDN은 지역 에지에 따라 다른 호스트 이름을 쓰기도 하므로, 한 번 잡은 서픽스가 다음 주에는 부족할 수 있습니다.

이때 필요한 것은 「유명한 한 줄 주소」가 아니라 실패 시각의 연결 로그 스냅샷입니다. 클라이언트에서 DOMAIN 필터를 걸어 NotebookLM 사용 중에만 나온 목록을 내보내 두면, 이후 규칙 정리가 반복 학습에 가까워집니다.

⑤ 개념 YAML: NotebookLM 스택을 한 덩어리로 올리기

아래는 개념 예시입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣어야 하고, 맨 아래 MATCH는 본인 정책에 맞게 조정합니다. GeoIP나 거대한 RULE-SET이 위에서 먼저 잡히면 이 줄들이 실행되지 않으니 순서를 꼭 확인하세요.

# Conceptual — verify hostnames from your logs; adjust width vs Gemini profile
rules:
  - DOMAIN-SUFFIX,notebooklm.google,PROXY
  - DOMAIN-SUFFIX,notebooklm.google.com,PROXY
  - DOMAIN-SUFFIX,accounts.google.com,PROXY
  - DOMAIN-SUFFIX,googleusercontent.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,storage.googleapis.com,PROXY
  # Optional if your logs show generic google.com hosts for the app shell
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,DIRECT

google.com 한 줄은 편하지만 범위가 넓습니다. 국내에 두고 싶은 구글 서비스가 있으면 Gemini 글에서 말한 것처럼 로그 기반으로 덜어내는 편이 안전합니다. 반대로 아무 것도 안 열릴 때는 잠시 MATCH,PROXY로 전역 비교만 해 보고 다시 좁히는 방법도 있습니다.

⑥ DNS: fake-ip·DoH·브라우저 직접 조회가 엇갈릴 때

증상이 호스트는 있는데 IP만 이상하다·간헐적 실패면 DNS 축을 의심합니다. fake-ip를 쓰는 프로필에서는 브라우저가 본 주소와 실제 라우팅이 어긋날 수 있고, 브라우저 HTTPS DNS(DoH)가 켜져 있으면 OS 리졸버와 병렬로 동작해 증상이 탭마다 다르게 보이기도 합니다. 재현 중에는 DoH를 잠시 끄고 같은 단계를 비교해 보는 것이 진단에 유리합니다.

Clash dns 블록에서 어떤 업스트림을 쓰는지, fallback이 있는지, IPv6를 어떻게 다루는지를 NotebookLM 사용 시나리오에 맞춰 통일하세요. TUN과 DNS의 관계는 TUN 모드 심화 글의 순서를 빌리면 빠릅니다.

⑦ 실측 순서: 로그 → 규칙 → DNS → 노드

1. 프로필 백업 후 Rule 모드에서 재현합니다.
2. NotebookLM에서 문서 열기·요약 실행·오디오 개요 생성·재생을 각각 나눠 시도합니다.
3. 각 단계 직후 Clash 로그에서 실패 timestamp 근처의 DOMAIN·정책·체인을 적습니다.
4. 빠진 DOMAIN-SUFFIX를 위로 올려 추가하고, 중복·상충 규칙이 없는지 봅니다.
5. 동일 증상이면 nslookup/dig와 브라우저 네트워크 탭의 실패 호스트를 대조합니다.
6. 마지막으로 다른 노드·프로토콜을 바꿔 긴 스트림만 불안정한지 확인합니다.

이 순서는 「핫 키워드」가 아니라 재현 가능한 체크리스트입니다. 처음이면 Clash 입문 튜토리얼에서 모드·프로필 개념을 익힌 뒤 적용하세요.

⑧ 모드·TUN·시스템 프록시와의 관계

Rule 모드는 위 규칙 순서를 그대로 따릅니다. 문제 분리용으로 Global을 잠깐 켜 노드 자체를 검증할 수는 있지만, 일상에는 대역폭과 지연 부담이 큽니다. 시스템 프록시만 켠 상태에서는 일부 데스크톱 앱이 트래픽을 빼돌리고, TUN은 더 많은 패킷을 규칙 아래로 끌어옵니다. 회사망·보안 에이전트와 겹치면 충돌이 나므로 정책을 먼저 확인해야 합니다. VPN과 규칙 프록시의 역할 차이는 Clash와 VPN의 차이에서 정리한 대로, 호스트 단위 정책이 필요하면 Clash 계열이 유리한 경우가 많습니다.

⑨ 보안·약관·조직 정책

네트워크 튜닝과 별개로 Google 서비스 이용 가능 지역·약관·학교/회사 IT 정책은 사용자가 직접 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다.

⑩ 한 줄 요약

NotebookLM은 notebooklm.google 표면뿐 아니라 API·정적 자산·긴 오디오·스토리지 호스트가 동시에 붙습니다. 증상을 UI·API·오디오로 나누고 로그를 모은 뒤 Clash 분류 규칙과 DNS를 세트로 맞추면, 단일 Gemini 웹 글과 다른 실측 루틴을 유지할 수 있습니다.

클라이언트는 릴리스만 쫓기보다 사이트 다운로드 페이지를 기준으로 잡는 편이 경로가 분명합니다. 규칙형 클라이언트는 로그와 함께 쓸 때 장기적으로 시간이 아낍니다. → Clash를 무료로 내려받고, NotebookLM 웹·오디오·API 호스트에 맞춰 분류와 DNS를 맞춰 보세요.