Notion AI가 멈추거나 동기화만 돌 때: Notion·AWS 도메인을 Clash(mihomo)로 분기하는 실측 단계 (2026)

1. 왜 단순 AI 글과 다른가: 협업 스택의 네트워크 모델

지식관리·프로젝트 위키 용도로 Notion을 쓰면, 한 세션 안에서도 요청 종류가 섞입니다. 문서 본문을 그리는 HTML·번들 자산, 실시간으로 상태를 맞추는 스트림 계열, 용량이 큰 파일 업로드·다운로드, 그리고 Notion AI를 눌렀을 때 뒤에서 이어지는 API 호출까지 병렬로 돌아갑니다. 이 중 일부는 notion.so·notion.com 트리에 남고, 다른 일부는 api.notion.com이나 리전이 붙은 AWS 엔드포인트, 혹은 *.cloudfront.net 형태의 CloudFront 배포로 빠져 나갑니다. 그래서 「한 줄짜리 오픈AI 도메인만 추가하면 된다」는 사고방식으로는 부족하고, Clash 분할에서도 도메인 규칙의 커버리지와 우선순위를 같이 봐야 합니다.

프록시 코어가 해 줄 수 있는 일은 관측된 호스트명을 일관된 정책 그룹으로 보내고, DNS 해석 경로가 규칙과 어긋나지 않게 맞추는 것까지입니다. 워크스페이스 권한, 결제 플랜, AI 기능의 지역 정책, 회사 SSO 같은 요인은 네트워크 분기와 별개이니, 증상을 좁힐 때 섞지 않는 편이 좋습니다. 기본 프로필 구성이 아직이라면 구독 가져오기로 먼저 안정적인 베이스를 만든 뒤, 아래 스니펫을 rules 상단 쪽에 합류시키는 흐름을 권합니다.

개발자가 모델을 받아오는 Hugging Face 글과 비슷하게, 지식 허브형 제품은 작은 JSON과 큰 바이너리가 한 화면에 공존합니다. 다만 Notion은 대역폭 피크보다 지연에 민감한 상호작용이 많아, 일부 서브요청만 다른 노드로 새거나 DIRECT로 떨어지면 UI 상태가 쉽게 깨집니다. 그 점에서 스트리밍 OTT 글과도 검증 포인트가 조금 다릅니다.

2. 흔한 증상: 동기화 스피너·첨부 지연·AI 무응답

제목 줄만 보이고 본문 블록이 비어 있거나, 상단에 동기화 표시가 길게 남는 경우는 API·실시간 채널 쪽이 막혔을 가능성이 큽니다. 데이터베이스 카드 썸네일·인라인 이미지가 계속 비어 있으면 CloudFront나 S3 버킷 호스트가 다른 정책으로 나가고 있을 때가 많습니다. 파일 업로드 진행률이 멈추면 대용량 PUT·세션 재개가 끊긴 것이고, Notion AI만 조용히 타임아웃하면 AI 전용 백엔드 호스트가 로그에 따로 찍히는지 확인할 가치가 있습니다.

「데스크톱 앱은 되는데 웹만 이상하다」면 OS 프록시·브라우저 DoH·확장 프로그램이 Clash 밖으로 새는지 의심합니다. 반대로 웹만 되고 앱이 이상하면 TUN 미사용 상태에서 앱이 시스템 프록시를 무시하는 패턴을 봅니다. 안드로이드 앱만 문제라면 Android 분앱 프록시 글과 교차해 출구를 맞춰 보세요.

디버깅의 첫 단계는 항상 같습니다. 브라우저 개발자 도구 Network 탭에서 pending·failed 요청의 Host를 적고, mihomo 디버그 로그에서 같은 호스트가 어떤 RULE에 걸렸는지 대조합니다. 가끔 재시도에 성공해 「저절로 나았다」처럼 보이는 경우도 있지만, 근본적으로는 규칙 순서와 DNS가 흔들리지 않게 고정해야 체감이 안정됩니다.

3. 단계별 도메인: 메인·API·AWS·CDN

아래 분류는 커뮤니티 규칙과 필드 로그에서 자주 보이는 출발점입니다. 인프라는 수시로 바뀌므로, 화이트리스트를 통째로 복사하기보다 관측 → 규칙 보강 루프를 전제로 두세요.

• 브랜드·앱 진입: notion.so, notion.com, 공개 페이지에 쓰이는 notion.site 등. 웹앱 껍데기와 라우팅에 해당합니다.
• API·백엔드: api.notion.com 및 *.notion.so 계열. 여기가 직행이면 「UI는 있는데 데이터가 안 들어온다」 패턴이 잘 납니다.
• 첨부·미디어(AWS): *.amazonaws.com 아래 버킷 호스트, 리전이 붙은 S3 스타일 이름. 대용량 전송이 이 축에 걸립니다.
• CDN: *.cloudfront.net. 썸네일·정적 자산이 여기로 갈라지면 메인과 다른 정책 그룹으로 나가는지 꼭 확인하세요.
• 계정·외부 로그인: Google·Apple 등 SSO를 쓰면 OAuth 관련 호스트가 추가됩니다. 기존 Google 분기 규칙과 순서가 충돌하지 않는지 같이 봅니다.

4. mihomo rules·proxy-groups 예시

mihomo에서는 넓은 GEOIP·MATCH보다 위쪽에 Notion 묶음을 두는 것이 안전합니다. 정책 그룹 이름 ▶️ Notion은 예시이며, 본인 구독의 셀렉터·노드 이름으로 바꿉니다. 병합 순서 개념은 고급 라우팅 가이드와 함께 읽으면 이해가 빨라집니다.

proxy-groups:
  - name: ▶️ Notion
    type: select
    proxies:
      - Stable-A
      - Stable-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,notion.so,▶️ Notion
  - DOMAIN-SUFFIX,notion.com,▶️ Notion
  - DOMAIN-SUFFIX,notion.site,▶️ Notion
  - DOMAIN,api.notion.com,▶️ Notion
  # Optional catch; trim if it collides with other traffic
  - DOMAIN-KEYWORD,notion,▶️ Notion
  - DOMAIN-SUFFIX,amazonaws.com,▶️ Notion
  - DOMAIN-SUFFIX,cloudfront.net,▶️ Notion
  # ... GEOIP PRIVATE, MATCH, etc.

5. DNS·Fake-IP·nameserver-policy 정렬

Fake-IP 모드는 도메인 기반 규칙과 궁합이 좋지만, 브라우저·OS의 DNS over HTTPS가 우선하면 해석이 코어 밖으로 새어 규칙과 실제 연결이 어긋날 수 있습니다. notion.so와 api.notion.com이 서로 다른 리졸버를 타면, TLS는 잡혀도 애플리케이션 계층에서 끊임없이 재시도하는 모호한 증상이 나옵니다. Claude 편에서 정리한 Fake-IP 점검표를 그대로 확장해, 「해석 결과의 출구」와 「로그에 찍힌 아웃바운드」가 같은 노드 풀을 가리키는지 먼저 확인하세요.

특정 접미만 지정 리졸버로 보내고 싶다면 nameserver-policy를 검토합니다. 예시는 참고용이며, 실제로 쓸 업스트림은 본인 정책에 맞게 교체합니다.

# Optional snippet — adjust resolvers to your policy
dns:
  nameserver-policy:
    "+.notion.so":
      - https://dns.google/dns-query
    "+.notion.com":
      - https://dns.google/dns-query

설정을 바꾼 뒤에는 OS·브라우저 세션 캐시가 남아 가짜 음성(false negative)을 만들 수 있습니다. 테스트 구간에서는 클라이언트를 한 번 재시작하거나 시크릿 창을 쓰는 것이 재현성을 높입니다. 전체 그림은 Clash 개요에서 DNS와 모드를 함께 보는 것도 좋습니다.

6. Sniffer·SNI와 로그 대조

연결이 먼저 IP 형태로 코어에 들어오면 DOMAIN 규칙을 건너뛰고 GEOIP나 MATCH로 떨어져, Notion의 일부 서브요청만 직행하는 상황이 생깁니다. 이때 Sniffer가 TLS ClientHello의 SNI에서 호스트명을 복원해 주면 다시 도메인 규칙으로 되돌릴 수 있습니다. 절차는 Sniffer·로그 대조 글의 순서를 그대로 밟되, Notion 세션처럼 병렬 요청이 많을 때는 규칙 우선순위와 스니퍼 옵션이 서로 부딪치지 않는지 확인하세요.

Sniffer는 편리하지만 호환성·프라이버시 트레이드오프가 있습니다. 회사 보안 에이전트·다른 VPN·로컬 필터가 동시에 있으면 로그가 서로 모순될 수 있으니, 재현 실험 때는 경로를 최대한 단순화하는 것이 좋습니다.

7. 검증 체크리스트와 함정

설정 후에는 다음을 순서대로 확인합니다. 첫째, 중간 크기 페이지를 열고 이미지 삽입·파일 업로드를 시도할 때 로그의 Host가 대부분 ▶️ Notion으로 모이는지. 둘째, 서드파티 규칙에 cloudfront.net이나 특정 리전 amazonaws.com을 과하게 DIRECT로 보내는 줄이 앞에 있지 않은지. 셋째, Fake-IP·nameserver-policy가 선택한 노드와 같은 출구를 가리키는지. 넷째, Wi-Fi와 LTE를 바꿔 증상이 재현되는지. 다섯째, Notion AI 전용 호스트가 로그에 따로 보이면 규칙을 한 줄 더 보강합니다.

흔한 함정은 notion.so 한 줄만 넣고 api.notion.com을 빼먹는 경우, 회사 방화벽이 WebSocket만 막아 놓은 것을 순수 DNS 문제로 오해하는 경우, 그리고 유지보수를 생각하지 않고 DOMAIN-KEYWORD를 과도하게 늘리는 경우입니다. 데스크톱과 웹을 같은 출구로 맞추려면 시스템 프록시만으로 부족할 때가 많으니, 필요하면 TUN으로 트래픽을 한 코어에 모으는 방안을 검토하세요.