1 왜 ChatGPT·OpenAI 전용 글로는 부족한가
OpenAI 튜토리얼은 api.openai.com·채팅 UI 호스트를 안정화하는 데 유리하지만, Notion은 문서 편집·실시간 협업·블록 저장소가 모두 Notion 인프라와 맞물립니다. 즉 한 호스트만 맞춰도 나머지가 DIRECT로 새면 쿠키·WebSocket·장시간 폴링이 끊겨 «한 화면은 되는데 저장이 안 된다»처럼 보입니다. Clash 분할 설계 시에는 «AI 제공자»가 아니라 «제품이 실제로 붙는 FQDN 묶음»을 기준으로 잡는 편이 재현성이 높습니다.
또한 Notion AI는 사용자 설정·리전·기능 플래그에 따라 백엔드 호출 패턴이 달라질 수 있어, 고정 목록만 믿기보다 Mihomo Connections 로그에서 실패 직전의 호스트를 한 번씩 확인하는 습관이 안전합니다. 클라이언트가 없다면 다운로드 페이지에서 GUI를 고른 뒤 Rule 모드 프로파일을 켜세요.
2 흔한 증상: 로그인 루프·동기 정지·AI 타임아웃
로그인 단계에서 브라우저는 notion.so 본문과 정적 자산·리디렉션 체인을 동시에 요청합니다. 이 중 일부만 다른 국가 노드로 나가면 세션이 성립하지 않아 «로그인 버튼만 돌아간다»는 패턴이 납니다. 동기는 페이지 데이터뿐 아니라 첨부·썸네일·실시간 편집 이벤트가 notionusercontent.com 등 CDN 축을 함께 쓰기 때문에, 본문만 프록시하고 업로드 호스트는 직행이면 업로드 큐가 멈춘 것처럼 보일 수 있습니다.
Notion AI 관련해서는 요약·번역·초안 생성 요청이 사용자 환경에서 추가 호스트를 동반할 수 있습니다. 증상이 «AI만 느리고 편집은 된다»이면, AI 요청만 다른 지연·차단 정책에 걸렸는지와 일반 API 호스트가 같은 프록시 그룹인지를 비교해 보세요. 반대로 전 구간이 느리면 노드 품질·MTU·DNS 쪽을 먼저 의심합니다.
3 핵심 도메인 축: 앱·웹·API·CDN
실무에서 먼저 묶어두면 디버깅이 쉬운 축은 다음과 같습니다. (1) 서비스 진입점인 notion.so·notion.com, (2) 공식 API와 연동 스크립트가 쓰는 api.notion.com, (3) 사용자 파일·이미지가 올라가는 notionusercontent.com 트리, (4) 공개 페이지 게시에 쓰이는 notion.site. 데스크톱·모바일 앱은 내부적으로 비슷한 호스트 집합을 쓰는 경우가 많아, DOMAIN-SUFFIX로 묶으면 클라이언트 종류를 일일이 나누지 않아도 됩니다.
팀에서 커스텀 도메인이나 엔터프라이즈 정책을 쓰면 추가 FQDN이 붙을 수 있습니다. 이때는 벤더 문서보다 실제 클라이언트가 붙는 호스트를 우선합니다. 넓은 DOMAIN-KEYWORD 한 줄보다 접미사 블록을 여러 개로 나누는 편이 오탐이 적습니다.
실시간 동기와 WebSocket
편집 세션은 장시간 연결을 유지합니다. 중간에 노드가 바뀌거나 TCP 세션이 끊기면 «저장 중» 표시만 남는 경우가 있어, url-test가 지나치게 공격적으로 노드를 바꾸지 않게 그룹을 설계하는 것도 중요합니다. 필요하면 url-test·fallback 글을 함께 보세요.
4 Notion AI 요청은 어디로 가는가
Notion AI는 제품 내부에서 기능 토글·모델 공급 구성에 따라 서로 다른 백엔드로 이어질 수 있습니다. 사용자 입장에서는 대부분 여전히 Notion 도메인 트리 안에서 완결되는 경우가 많지만, 조직 설정에 따라 외부 모델 게이트웨이가 추가될 여지도 있습니다. 본문은 «OpenAI 도메인만 따로 모아 끝»이 아니라는 점을 분명히 합니다. 증상이 AI에만 국한되면 Connections에서 AI 클릭 직후의 호스트를 확인하고, 그 호스트를 전용 Rule Provider 줄에 넣어 팀과 공유하세요.
이미 Gemini나 Claude 전용 그룹을 쓰고 있다면, Notion AI가 그 호스트를 직접 부르는지 여부를 로그로 확인한 뒤에만 외부 그룹과 합치세요. 추측으로 규칙을 섞으면 오히려 순환이 납니다.
5 SSO·Google·Apple 로그인이 섞일 때
조직에서 SSO나 소셜 계정을 쓰면 accounts.google.com 같은 아이덴티티 호스트가 추가됩니다. 이 트래픽을 Notion과 다른 출구로 보내면 인증 쿠키가 끊겨 로그인만 실패할 수 있으니, IdP·소셜 제공자용 규칙을 별도 블록으로 두되 한 번의 로그인 플로우 안에서 리디렉션이 모두 성공하는지 브라우저 개발자 도구로 확인하세요. 회사 HTTP 프록시와 Clash 시스템 프록시가 이중으로 겹치지 않게 한 겹만 남기는 것도 같은 이유입니다.
터미널·CI에서 notion CLI나 스크립트를 돌릴 때는 환경 변수 HTTPS_PROXY와 앱의 시스템 프록시 설정이 엇갈리지 않게 맞추고, 필요하면 TUN 모드로 경로를 통일합니다.
6 DOMAIN-SUFFIX와 규칙 순서
Clash 분할에서 규칙은 위에서 아래로 적용됩니다. 거대한 GEOSITE 묶음이 notion.so보다 위에 있으면 의도한 전용 그룹에 닿기 전에 흡수됩니다. PROXY-NOTION 같은 그룹을 만들었다면 (1) 팀이 합의한 Notion 접미사 블록, (2) 그 아래에 더 일반적인 규칙 순으로 읽기 쉽게 배치하세요.
OpenRouter처럼 API 대시보드 전용 글에서 쓰는 키워드 규칙과 섞일 때는, 좁은 접미사가 넓은 키워드보다 위에 오도록 순서를 재점검합니다.
7 Rule Provider로 목록을 버전 관리하기
호스트가 늘어날수록 YAML에 직접 붙여 넣기보다 사내 Git에 텍스트 목록을 두고 Rule Provider로 가져오는 편이 유지보수에 유리합니다. behavior: classical 목록을 올려 두고 RULE-SET,notion-2026,PROXY-NOTION처럼 참조하면 긴급 한 줄은 수동 규칙으로, 주간 동기화는 Provider로 나눌 수 있습니다.
팀 베이스 위에 로컬만 덧씌우려면 mixin·구독 덮어쓰기를 활용하고, 구독 형식이 다르면 구독 변환 가이드로 맞춘 뒤 규칙을 얹으세요.
8 YAML 예시 (개념 스니펫)
아래는 병합용 예시입니다. PROXY-NOTION은 본인의 proxy-groups 이름에 맞추고, 상위 규칙과 충돌하지 않게 순서를 조정하세요. 배포 전에는 반드시 Connections 로그로 검증합니다.
# Notion product surface (web + app + API + public sites)
- DOMAIN-SUFFIX,notion.so,PROXY-NOTION
- DOMAIN-SUFFIX,notion.com,PROXY-NOTION
- DOMAIN-SUFFIX,notion.site,PROXY-NOTION
- DOMAIN-SUFFIX,api.notion.com,PROXY-NOTION
- DOMAIN-SUFFIX,notionusercontent.com,PROXY-NOTION
# If your org uses custom domains, add explicit DOMAIN-SUFFIX lines above catch-all rules.
# Keep this block above overly broad GEO / keyword catch-all rules.
api.notion.com은 FQDN 그대로 두어도 되고, 상위 접미사 정책과 맞추려면 팀 규칙에 따라 조정합니다. 스트리밍이나 장시간 세션이 많다면 노드 전환을 줄이는 구성이 유리합니다.
9 DNS·TUN·시스템 프록시
규칙이 맞아도 DNS가 ISP 쪽으로 새면 지역 응답이 어긋나 매칭 전에 실패하는 것처럼 보입니다. DoH·FakeIP 가이드에 맞춰 Clash DNS·OS 리졸버·TUN을 정렬하세요. 브라우저 확장이 별도 프록시를 켜 두면 본문 규칙과 충돌하므로, IDE·브라우저·시스템의 기본 경로를 한 번에 그려 보는 것이 좋습니다.
10 트러블슈팅 체크리스트
- 로그인만 실패:
notion.so와 정적·리디렉션 호스트가 같은 그룹인지, SSO·소셜 호스트가 끊기지 않았는지 확인합니다. - 편집은 되는데 첨부·썸네일만 안 됨:
notionusercontent.com축이 다른 출구로 갈렸는지 봅니다. - 동기 지연만 심함: WebSocket·장세션 안정성, 노드 지연·지터를 점검합니다.
- API 스크립트만 실패:
api.notion.com과 토큰 환경 변수·시스템 프록시 불일치를 확인합니다. - 간헐적 신규 호스트: 로그를 캡처해 Rule Provider에 반영합니다.
11 정책·보안·올바른 사용
연결이 안정되어도 Notion·Notion AI 이용약관과 조직 보안 정책은 그대로 적용됩니다. 본문은 합법적인 업무 환경에서 Clash 분할을 정돈하는 방법을 설명할 뿐, 통제된 네트워크를 우회하라는 뜻이 아닙니다. API 키와 내부 문서는 최소 권한으로 다루세요. 클라이언트 소스는 공개 저장소에서 확인할 수 있으나, 설치 패키지는 사이트 다운로드 페이지를 우선하는 편이 출처 관리에 유리합니다.
12 정리
2026년 Notion AI와 팀 협업 수요가 커질수록, «범용 AI 사이트만 맞추면 된다»는 가정은 Notion 클라이언트 문제를 놓치기 쉽습니다. 로그인·동기·API·CDN 축을 notion.so·api.notion.com·notionusercontent.com 등 접미사로 묶고, DOMAIN-SUFFIX 순서와 Rule Provider로 재현 가능한 출구를 유지하는 것이 핵심입니다. 검색형 웹앱·노트 조합은 각각 Perplexity·NotebookLM 글과 역할을 나누면 주제 중복을 피할 수 있습니다.
동일한 GUI에서 프로파일을 공유하면 팀원이 같은 Clash 분할로 Notion 경로를 재현하기 쉽습니다. Rule 편집기와 로그 뷰가 한눈에 들어오는 클라이언트를 고르면 운영 부담이 줄어듭니다.
