2026년 Clash로 NotebookLM 안정 사용:
Google 분할·DOMAIN-SUFFIX·Rule Provider

1 왜 NotebookLM만 따로 규칙 묶음을 두는가

많은 구독 규칙에 «Google = DIRECT» 또는 «Google = 글로벌 프록시» 한 줄이 들어 있습니다. 검색·YouTube·Gmail까지 한꺼번에 처리하기엔 편하지만, NotebookLM은 UI가 notebooklm.google.com에 있고, 로그인·동의는 accounts.google.com 등 계정 호스트로 넘어가며, 소스 처리·모델 호출은 googleapis.com 아래 여러 서브도메인으로 흩어질 수 있습니다. 여기서 한 축만 다른 정책을 타면 «화면은 뜨는데 업로드만 실패»처럼 반쪽 성공 패턴이 나옵니다.

Clash·Mihomo의 규칙 분할은 위 호스트를 의도한 프록시 그룹으로 보내 재현성을 높이는 데 유리합니다. 목표는 지연 자랑이 아니라, Connections 로그에서 같은 작업(로그인, PDF 추가, 노트 생성)마다 동일한 출구가 찍히게 만드는 것입니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 Rule 모드로 프로파일을 적용하세요.

NotebookLM은 Gemini 제품군과 맥락이 비슷하지만, 실제 SNI는 문서·업로드·백엔드 조합이 다를 수 있으므로 로그로 검증하는 것이 안전합니다.

2 어떤 도메인·트래픽 축을 같이 봐야 하는가

소비자용 웹앱은 보통 notebooklm.google.com이 중심입니다. 마케팅·리다이렉트로 notebooklm.google 형태의 호스트가 보일 수 있으니, 브라우저 주소창과 개발자 도구의 네트워크 탭을 함께 확인하세요. 정적 자산·폰트는 gstatic.com, 사용자 콘텐츠·업로드와 연관된 호스트로 googleusercontent.com·storage.googleapis.com 계열이 로그에 나타나는 경우가 많습니다.

Google 계정 세션은 accounts.google.com·oauth 관련 리다이렉트와 엮입니다. Drive·Docs에서 소스를 가져오는 흐름이면 docs.google.com·drive.google.com 경로가 추가됩니다. 백엔드는 넓은 googleapis.com 아래 서브도메인으로 이어지는 경우가 일반적이며, 엔터프라이즈·관리 콘솔 시나리오에서는 notebooklm.cloud.google.com과 *-discoveryengine.googleapis.com 같은 패턴이 문서에 나옵니다. 정확한 FQDN은 제품 업데이트로 바뀔 수 있으므로, 클라이언트의 연결 로그를 스냅샷으로 모아 규칙을 보강하는 방식이 장기적으로 덜 깨집니다.

3 범용 Google 규칙과의 우선순위·충돌

Clash 분할에서 규칙은 위에서 아래로 매칭됩니다. GEOSITE,google 또는 아주 넓은 DOMAIN-SUFFIX,google.com 줄이 NotebookLM보다 위에 있으면, 의도한 전용 그룹보다 먼저 흡수됩니다. 반대로 NotebookLM을 아주 좁게만 적어 두고 그 아래에 «나머지 Google은 DIRECT»가 있으면, 로그에 새로 뜬 서브도메인만 다른 출구로 새어 나가기 쉽습니다.

실무에서는 (1) NotebookLM·계정·핵심 API를 한 그룹으로 보내는 구체 규칙을 (2) 광범위 Google Rule Provider나 GEOIP 규칙보다 앞에 두는 패턴이 흔합니다. «Google 전체 DIRECT»를 유지하고 싶다면, NotebookLM 관련 호스트만 예외로 PROXY-NOTEBOOK 같은 그룹에 보내는 식으로도 설계할 수 있습니다. 중요한 것은 팀·본인 프로파일 안에서 한 가지 이야기로 통일하는 것입니다.

DOMAIN-KEYWORD,notebooklm은 진단용으로는 빠르지만, 오탐 가능성이 있어 장기 규칙에는 DOMAIN-SUFFIX,notebooklm.google.com 등 접미사 위주가 낫습니다. 키워드 규칙을 쓸 때는 로그로 실제 매칭을 확인하세요.

4 DOMAIN-SUFFIX·rules 예시 (개념 스니펫)

아래는 병합용 예시입니다. PROXY-NOTEBOOK 이름은 본인 proxy-groups와 일치시키고, 상위 구독 규칙과 중복되면 한쪽으로 합치세요.

# NotebookLM + shared Google stack → same proxy group (example)
- DOMAIN-SUFFIX,notebooklm.google.com,PROXY-NOTEBOOK
- DOMAIN-SUFFIX,notebooklm.cloud.google.com,PROXY-NOTEBOOK
- DOMAIN-SUFFIX,accounts.google.com,PROXY-NOTEBOOK
- DOMAIN-SUFFIX,googleapis.com,PROXY-NOTEBOOK
- DOMAIN-SUFFIX,gstatic.com,PROXY-NOTEBOOK
- DOMAIN-SUFFIX,googleusercontent.com,PROXY-NOTEBOOK

# If logs show storage or OAuth hosts, add explicitly:
# - DOMAIN-SUFFIX,storage.googleapis.com,PROXY-NOTEBOOK
# - DOMAIN-SUFFIX,docs.google.com,PROXY-NOTEBOOK
# - DOMAIN-SUFFIX,drive.google.com,PROXY-NOTEBOOK

googleapis.com을 넓게 잡으면 다른 Google API 트래픽까지 같은 그룹으로 갑니다. 업무상 분리가 필요하면 Connections 로그에서 NotebookLM 작업 시에만 등장하는 호스트를 골라 좁히는 2단계 접근이 현실적입니다. 구독 YAML 형식이 맞지 않으면 구독 변환 가이드로 먼저 정규화하세요.

5 Rule Provider로 목록을 외부화하기

팀 단위로 규칙을 맞출 때는 텍스트 파일이나 원격 YAML을 Rule Provider로 두고 주기적으로 갱신하는 방식이 편합니다. behavior: classical 또는 도메인 목록에 맞는 behavior를 선택하고, rules:에서 RULE-SET,provider-name,PROXY-NOTEBOOK처럼 참조합니다. 신뢰할 수 있는 출처의 목록만 쓰고, 구독 업데이트가 로컬 커스텀 규칙을 덮어쓰지 않게 mixin·프로파일 병합 순서를 점검하세요.

커뮤니티 제공 Google 세트와 본인이 만든 NotebookLM 보강 블록을 동시에 쓸 때는 중복 매칭보다 순서가 우선입니다. 같은 호스트가 두 번 정의되어도 위쪽이 이기므로, «보강 블록을 Provider보다 위»에 두는지 여부를 팀 규약으로 정해 두면 혼선이 줄어듭니다.

6 NotebookLM Enterprise·Google Cloud 경로

조직용 NotebookLM Enterprise는 UI가 notebooklm.cloud.google.com 쪽으로 열리는 경우가 있고, API 문서에는 ENDPOINT_LOCATION-discoveryengine.googleapis.com 형태의 호스트가 등장합니다. 개인용 프로파일에 엔터프라이즈 URL을 미리 넣어 두면, 나중에 조직 계정으로 전환할 때 규칙을 다시 헤매지 않아도 됩니다. 콘솔·IAM·결제 관련은 console.cloud.google.com 등 추가 호스트가 붙을 수 있어, 관리자 가이드와 실제 브라우저 로그를 대조하는 것이 안전합니다.

이 글은 소비자 웹앱을 기준으로 설명하지만, 엔터프라이즈는 프로젝트·리전에 따라 엔드포인트가 달라질 수 있습니다. 네트워크 정책이 막혀 있으면 프록시만으로는 403·쿼터 메시지가 사라지지 않을 수 있으니, IAM과 API 활성화 상태도 함께 확인하세요.

7 TUN·DNS로 세션·이름 해석 맞추기

브라우저는 프록시를 타는데 백그라운드 요청만 직행하는 패턴은 흔합니다. TUN 모드로 시스템 트래픽을 한 규칙 엔진에 넣으면 NotebookLM 탭과 업로드 세션이 같은 출구를 쓰기 쉽습니다. VPN·회사 터널과 겹치면 지연이 커질 수 있으니 정책 범위 안에서만 적용하세요.

이름 해석이 ISP로 새면 규칙이 맞아도 간헐 실패가 납니다. DNS·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. Google 호스트는 지역별 응답 차이가 있어, 노드를 바꿀 때마다 지연이 달라질 수 있습니다.

8 로그인·PDF 업로드·요약 실패: 점검 순서

아래는 네트워크 측면에서의 일반적인 순서입니다. 앱 자체 장애·계정 제한과 구분해야 할 때가 많습니다.

• 로그인 루프·세션 만료: accounts.google.com과 notebooklm.google.com이 같은 프록시 그룹인지, 쿠키 도메인이 차단되지 않았는지 확인합니다. 브라우저 확장 광고 차단이 OAuth 리다이렉트를 막는 경우도 있습니다.
• PDF·파일 업로드만 실패: 업로드 세션용 googleusercontent.com·storage.googleapis.com·대용량 전송 호스트가 로그에 찍히는지 봅니다. DIRECT로만 나가다 차단되면 TLS 단계에서 끊길 수 있습니다.
• 요약·생성이 중간에 멈춤: 장시간 스트리밍 응답은 불안정한 노드에서 끊깁니다. 노드를 고정한 채 같은 프롬프트를 반복해 보고, HTTP/2·WebSocket 경로가 타임아웃인지 Connections에서 확인합니다.
• 브라우저만 되고 다른 앱은 실패: 시스템 프록시를 무시하는 프로세스가 있는지, HTTPS_PROXY·NO_PROXY에 Google 호스트가 잘못 제외되어 있지 않은지 봅니다.
• IPv6 경로 불일치: IPv6가 직통·IPv4만 프록시일 때 증상이 납니다. 환경에 맞게 v6 정책을 정리합니다.

9 계정·약관·망 정책

연결이 되어도 지역·라이선스·조직 정책 메시지는 프록시로 해결되지 않을 수 있습니다. 학교·회사망·국가 규정을 위반하지 않는 범위에서만 구성하세요. 오픈 소스 클라이언트의 소스는 GitHub 등에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.

10 정리

2026년에도 NotebookLM은 Google 계정·광범위 googleapis 호스트와 함께 움직이므로, 제품 이름보다 실제 SNI·FQDN 기준으로 Clash 분할을 잡는 편이 안전합니다. DOMAIN-SUFFIX로 진입점·계정·API 축을 전용 프록시 그룹에 묶고, 범용 Google Rule Provider보다 앞에 두면 우선순위 혼선이 줄어듭니다. Mihomo 계열 GUI에서는 Rule 모드·TUN·DNS를 한 줄로 맞추고, Gemini·AI Studio와 출구를 공유하면 Google AI 스택 전반이 다루기 쉬워집니다. 다른 범용 AI 글들과 마찬가지로, 규칙 가독성과 클라이언트 선택 폭에서 실무 만족도가 높은 편입니다.

설치와 릴리스 정보는 Clash 다운로드 페이지에서 OS별로 확인할 수 있습니다.

→ Clash 무료 다운로드로 NotebookLM용 분할 규칙을 적용해 보세요