2026년 Notion AI가 막히거나 동기화가 불안정할 때: Clash 도메인 분류·DNS·실측

① 왜 Notion은 「ChatGPT용 RULE-SET 한 장」으로 끝내기 어렵나

Notion 클라이언트는 로그인·페이지 렌더·블록 저장·검색·첨부 업로드·실시간 협업·Notion AI 요청이 서로 다른 호스트와 프로토콜(WebSocket·HTTP/2·REST)로 갈릴 수 있습니다. TLS에서 보이는 SNI 이름이 제품 메인 도메인 하나로만 정리되지 않고, 문서에 따라 api.notion.com 계열과 웹 셸 notion.so 계열이 동시에 등장하는 패턴이 흔합니다. 동기화·알림·메시지 저장소로 자주 거론되는 msgstore류 서브도메인과, 첨부·이미지를 위한 객체 스토리지·CDN 호스트가 로그에 따로 붙을 수도 있습니다.

그래서 「한 줄 DOMAIN-SUFFIX,openai.com」 식의 범용 AI 규칙만 넓게 켜 두면, Notion 웹은 되는데 API만 DIRECT로 나가 작업이 중간에 멈춘 것처럼 보이거나, 반대로 동기화만 간헐적으로 실패하는 식으로 증상이 어긋날 수 있습니다. 규칙 문법이 처음이면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 익히면 실수가 줄어듭니다.

② 증상부터 나누기: 웹만·앱만·동기화만·AI만

같은 「안 열린다」라도 원인 후보가 다릅니다. 아래처럼 먼저 쪼개 두면 Clash 로그와 브라우저 개발자 도구의 네트워크 탭을 병행하기 쉽습니다.

• 브라우저 탭만: 로그인·페이지 목록은 되는데 특정 블록·임베드·미디어만 실패 → 정적 자산·임베드 대상 호스트가 빠졌을 가능성
• 데스크톱·모바일 앱만: OS DNS 캐시·배터리 최적화·회사 MDM 정책이 웹과 달라 동일 YAML이라도 체감이 갈림
• 동기화·충돌 메시지: 실시간 채널·메시지 저장소 호스트가 PROXY 정책과 어긋나거나, 한쪽만 느린 노드로 나감
• Notion AI만: 본문 편집은 되는데 AI 패널만 오류 → AI 요청이 별도 경로·권한·지역 정책에 걸리는 경우(네트워크 외 약관·플랜 이슈도 함께 확인)

다른 생성 AI 전용 글과 비교하려면 Perplexity 분류의 호스트 표와 나란히 두고, 노트·협업 제품에만 필요한 줄이 무엇인지 구분해 보세요.

③ 분류 대상: 로그에서 자주 보이는 Notion 계열 호스트 후보

아래는 출발점으로 쓸 수 있는 후보이며, 제품 업데이트와 지역·워크스페이스 설정에 따라 달라질 수 있습니다. 확정은 항상 Clash 연결 로그와 앱·브라우저의 실제 요청 이름으로 맞추는 것이 좋습니다.

• 웹·앱 셸: notion.so, www.notion.so
• 공개 API: api.notion.com — 자동화·연동·일부 클라이언트 기능이 REST로 갈라짐
• 동기화·메시지: 환경에 따라 msgstore.notion.so 등 실시간·저장소 계열 서브도메인이 로그에 따로 보일 수 있음
• 첨부·미디어: 객체 스토리지·CDN 호스트가 *.amazonaws.com 등으로 잡히는 경우가 있어, 과도하게 넓은 DOMAIN-SUFFIX는 다른 서비스까지 끌고 올 수 있음
• 마케팅·문서 사이트: notion.com 등 리다이렉트·온보딩에만 쓰이는 이름이 섞일 수 있음

첨부 호스트를 한 번에 거대 RULE-SET으로 밀어 넣기보다, 실제로 실패한 요청의 도메인을 기준으로 DOMAIN-SUFFIX를 쌓는 편이 안전합니다. IPv6 우선 해석 뒤 특정 구간에서만 끊기면 OS·코어의 IPv4/IPv6 일관성도 함께 봅니다.

④ 최소 규칙 예시: notion.so·api.notion.com을 PROXY, 나머지는 환경에 맞게

아래는 개념 YAML입니다. PROXY 자리에는 구독 프로필의 프록시 그룹 이름을 넣고, 맨 아래 MATCH는 국내 트래픽 DIRECT 등 본인 정책에 맞게 조정하세요.

rules:
  # Notion — add hosts seen in your client logs after product updates
  - DOMAIN-SUFFIX,notion.so,PROXY
  - DOMAIN,api.notion.com,PROXY
  - DOMAIN-SUFFIX,notion.com,PROXY
  - MATCH,DIRECT

api.notion.com을 빼면 웹 UI는 되는데 연동·백그라운드 저장만 실패하는 식으로 갈릴 수 있습니다. 첨부·스토리지가 별도 호스트로 잡히면 그때그때 로그에 맞춰 줄을 추가합니다. 아무 것도 매칭되지 않을 때는 잠시 MATCH,PROXY로 바꿔 노드·터널 자체가 정상인지부터 가르는 것도 좋은 디버깅 순서입니다. 반대로 국내 사이트까지 느려지면 범위가 과한 것이니, 다시 좁혀 나가면 됩니다.

⑤ 웹·API·동기화를 나누고 싶을 때: 프록시 그룹을 둘 이상

지연·안정성 때문에 브라우저와 API·스크립트에 서로 다른 출구를 쓰고 싶다면 그룹을 나눠 규칙에서 이름만 바꿉니다. 예시는 구조 이해용이며, 실제 노드 목록은 본인 구독에 맞게 바꿉니다.

proxy-groups:
  - name: NOTION_WEB
    type: select
    proxies: [🚀 자동 선택, DIRECT]
  - name: NOTION_API
    type: select
    proxies: [🚀 자동 선택, DIRECT]

rules:
  - DOMAIN-SUFFIX,notion.so,NOTION_WEB
  - DOMAIN,api.notion.com,NOTION_API
  - MATCH,DIRECT

이렇게 나누면 「웹만 간헐적으로 실패한다」일 때 NOTION_WEB만 노드를 바꿔 테스트하기 쉽습니다. 그룹 중첩·이름 짓기는 프록시 그룹(proxy-groups) 가이드와 함께 보면 정리가 수월합니다.

⑥ 규칙 우선순위: 위에서 아래로, 앞줄이 이긴다

Clash의 rules는 일반적으로 먼저 매칭된 한 줄이 최종 정책이 됩니다. 그래서 GEOIP,KR,DIRECT나 구독에 포함된 RULE-SET이 notion.so 관련 줄보다 위에 있으면, 의도와 다르게 DIRECT로 나가 버릴 수 있습니다. 반대로 지나치게 아래에 두면 이미 MATCH에 걸려 끝나기도 합니다.

재현이 어려울 때는 로그의 매칭된 규칙 이름·행 순서를 남겨 두고, 한 번에 한 줄만 위아래로 옮겨 보는 방식이 안전합니다. 범용 AI RULE-SET과 커스텀 줄이 같이 있을 때는, Notion 전용 줄이 실제로 먼저 적중하는지를 숫자로 확인하는 것이 중요합니다.

⑦ DNS가 원인일 때: fake-ip, DoH, 조회 경로 엇갈림

증상이 「느리다」가 아니라 간헐적 이름 실패·한 앱만 이상한 IP라면 DNS를 의심합니다. fake-ip 프로필에서는 애플리케이션이 보는 주소와 실제 outbound 경로가 어긋나 보일 수 있고, OS나 브라우저 DoH가 켜진 채 Clash dns 블록도 동작하면 어느 쪽이 먼저 응답했는지에 따라 결과가 달라집니다. 장시간 켜 둔 동기화 세션은 DNS·연결 재시도 타이밍에 특히 민감합니다.

TUN과 DNS를 같이 쓸 때의 절차는 TUN 모드·DNS 심화 글의 순서를 참고하면 후보를 빠르게 줄일 수 있습니다.

⑧ 모드 선택: Rule, Global, Direct와 시스템 프록시·TUN

Rule 모드는 앞서 정한 rules 순서대로 매칭합니다. 문제를 처음 재현할 때는 Global을 잠깐 켜서 노드 품질부터 가르는 것이 유용합니다. 시스템 프록시는 프록시를 존중하는 앱 위주로 동작하고, TUN은 가상 NIC로 더 많은 트래픽을 끌어와 규칙 적용을 일관되게 만들 수 있습니다. 회사 PC에서는 사내 VPN·보안 에이전트와 충돌할 수 있으니 정책을 먼저 확인해야 합니다.

전역 터널과 규칙 기반의 장단은 Clash와 VPN의 차이에서 정리한 대로, 호스트 단위 정책이 필요하면 Clash 쪽이 유리한 경우가 많습니다.

⑨ 실측 절차: 페이지 하나를 편집·동기화·AI까지 한 번에 밟으며 로그에 맞추기

1. 프로필 백업: YAML 내보내기 또는 클라이언트 백업으로 현재 설정을 저장합니다.
2. Rule 모드: 선택된 프록시 그룹이 의도와 같은지, 상위 GEOIP 등이 notion.so보다 먼저 먹지 않는지 확인합니다.
3. 단일 워크스페이스 테스트: 브라우저에서 페이지 하나만 연 뒤 Clash 로그에서 매칭된 DOMAIN·정책을 확인하고, 빠진 서픽스를 추가합니다.
4. 동기화 확인: 다른 기기에서 같은 블록을 수정해 충돌 없이 반영되는지, 실패 시 로그에 메시지 저장소 호스트가 새로 뜨는지 봅니다.
5. DNS 분리: 실패가 규칙인지 해석인지 나누기 위해 OS 도구와 브라우저 네트워크 탭을 병행합니다.
6. Notion AI: AI 기능을 한 번 호출한 뒤, 동일 세션에서 추가로 뜨는 호스트가 있는지 로그로 확인합니다.
7. 회귀 테스트: 규칙을 고친 뒤에는 국내 뱅킹·사내 포털 등 민감 사이트가 의도대로 DIRECT인지도 함께 확인합니다.

처음 클라이언트를 쓴다면 Clash 입문 튜토리얼에서 프로필·모드 개념을 익힌 뒤 이 체크리스트를 적용하면 훨씬 덜 헷갈립니다.

⑩ 보안·정책·서비스 약관을 함께 기억하기

네트워크 경로를 다루는 방법과 별개로, 이용 가능 지역·워크스페이스 정책·조직 보안 규정은 사용자가 스스로 확인해야 합니다. 이 글은 합법적 범위에서의 연결 품질·분류를 기술적으로 설명하는 것이며, 특정 규제를 우회하라는 뜻으로 읽혀서는 안 됩니다. 기업 환경에서는 IT 부서의 프록시·DLP 정책을 우선합니다.

⑪ 정리: Notion은 「도메인·DNS·동기화·AI」를 한 세트로 보라

2026년에도 Notion과 Notion AI에 대한 관심은 지식·업무 도구 검색에서 이어지고, 네트워크 경로만으로 해결되지 않는 증상(플랜·권한·지역 정책)도 있습니다. 그럼에도 Clash로 관측 가능한 범위에서는 도메인 분류가 빠짐없이 매칭되는지, DNS가 같은 경로를 보는지, 규칙 표에서의 순서가 의도와 맞는지에 따라 체감이 갈립니다. 단일 챗봇 중심 글과 달리, 노트·동기화·AI가 한 앱에 섞이므로 로그를 통한 보강이 특히 중요합니다.

설치와 버전 안내는 릴리스만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 혼선이 적습니다. 전역 터널보다 관측 가능한 분류에서 Clash가 장기적으로 잘 맞는 경우가 많습니다. → Clash를 무료로 내려받고, Notion·Notion AI용 도메인 규칙과 DNS를 맞춰 보세요.