동기 스피너가 길어질 때: 한 화면처럼 보여도 호스트는 여럿이다

Notion 웹이나 Electron 기반 데스크톱 앱은 겉으로는 하나의 제품처럼 보이지만, 실제 HTTPS·WebSocket·업로드 세션은 notion.so 계열과, 객체·썸네일·API에 가까운 AWS·CloudFront·리전별 엔드포인트로 갈라집니다. 그중 일부만 DIRECT에 남고 나머지는 느린 노드·다른 지연 프로파일을 타면, UI는 “거의 됨”인데 백그라운드 요청만 pending으로 남아 동기 실패·무한 스피너로 느껴집니다. Clash의 연결 로그에 찍히는 도메인·SNI를 먼저 모으는 것이 timeout·TLS 원인을 노드 탓만 하지 않게 하는 첫걸음입니다.

흔한 실수는 “메인 도메인만 프록시에 넣으면 된다”는 가정입니다. www.notion.so만 정책에 있고 CDN·*.amazonaws.com·*.cloudfront.net 류가 GEOIP나 거친 KEYWORD에 먼저 잡히면, 같은 문서 편집 세션 안에서도 출구가 섞입니다. TUN 모드로 시스템 전체를 한 프로필에 올리거나, 반대로 브라우저만 시스템 프록시를 탈 때는 데스크톱 앱이 빠져 “웹만 됨”이 생길 수 있으니, 증상을 재현한 클라이언트부터 고정합니다.

ℹ 세 줄 정리: (1) DevTools 네트워크 탭·Clash 라이브 연결에 동시에 기록한다. (2) notion·makenotion·amazonaws·cloudfront 등 실제 호스트를 날짜와 함께 목록화한다. (3) fake-ip·Meta DNS가 규칙과 같은 출구 결론을 내는지 맞춘다.

디자인 툴·AI 챗·M365 글과 무엇이 다른가

Figma·Adobe 글은 캔버스·폰트·Creative Cloud 자산에 초점이 있고, ChatGPT·DeepSeek 류는 추론 API·채팅 호스트가 중심입니다. Microsoft 365·GitHub Copilot은 microsoft.com·마켓·개발 백엔드에 무게가 실립니다. Notion은 지식 베이스·블록 DB·실시간 협업에 맞춰 제품 전용 호스트 지도가 따로 필요합니다. 범용 “큰 규칙 세트”만 켜 두면 빈칸이 남아 동기만 간헐적으로 깨지는 패턴이 반복됩니다.

대용량 파일·이미지가 많은 팀은 Hugging Face 같은 “모델·CDN” 글과 비슷하게, 다운로드 전용 정책을 분리하는 사고방식이 도움이 됩니다. 다만 Notion은 브라우저 앱과 동일 계정 세션을 공유하므로, 출구를 지나치게 쪼개면 오히려 세션·리전 표시가 엇갈릴 수 있어, 정책 그룹·fallback 설계와 함께 보는 것이 안전합니다.

Notion: 앱·웹·공개 페이지·실시간 편집

실무에서 출발점으로 삼기 좋은 접미사는 notion.so·notion.site(공개 페이지)·필요 시 makenotion.com(브랜드·마케팅·일부 리다이렉트) 등입니다. 제품이 바뀌면 호스트가 늘거나 줄 수 있으므로, 커뮤니티에 떠도는 YAML을 그대로 믿기보다 본인 워크스페이스를 열었을 때의 네트워크 탭을 기준으로 삼습니다. 실시간 편집·댓글·권한 확인은 WebSocket에 가까운 긴 연결을 쓰는 경우가 많아, 중간에서 RST·타임아웃이 나면 “가끔만 저장 안 됨”처럼 보입니다.

데스크톱 앱은 Electron 계열이라 브라우저와 같은 호스트를 쓰는 경우가 많지만, OS 방화벽·제로트러스트·앱 자체 프록시 설정에 따라 경로가 달라질 수 있습니다. 클라이언트별로 TUN·시스템 프록시·PAC 적용 범위를 확인하고, 한 번에 한 옵션만 바꿔 규칙 적중을 비교합니다.

AWS·엣지·amazonaws.com·cloudfront.net 층

로그를 보면 API 게이트웨이·S3 스타일·Lambda@Edge에 가까운 패턴으로 *.amazonaws.com, 또는 *.cloudfront.net 호스트가 함께 찍히는 경우가 많습니다. 서비스가 어떤 리전을 쓰는지에 따라 하위 도메인 문자열이 길고 난해해, DOMAIN-KEYWORD,amazonaws처럼 넓게 잡는 유혹이 생깁니다. 그러나 그렇게 하면 다른 업무용 AWS SDK 트래픽까지 한꺼번에 끌려와 부작용이 큽니다. 우선은 관측된 정확한 FQDN을 DOMAIN으로 박고, 반복되는 패턴만 DOMAIN-SUFFIX로 승격하는 편이 운영에 유리합니다.

일부 환경에서는 이미지·첨부가 긴 URL의 서명된 링크로 뜨며, 짧은 TTL 동안만 유효합니다. 이런 URL은 규칙 세트에 “영구 목록”으로 넣기 어렵기 때문에, 상위 CDN 접미사와 메인 앱 도메인을 같은 정책 의도(NOTION)로 묶어 두고, 로그로 새 호스트가 생겼는지 주기적으로 재수집하는 방식이 현실적입니다.

정책 그룹: NOTION 한 의도로 묶기

예시로 NOTION_APP 하나에 메인·API·엣지를 모두 넣거나, 업로드가 길어지는 회선만 NOTION_CDN으로 쪼갤 수 있습니다. 핵심은 “같은 사용자 세션에서 기대하는 지연·지역이 비슷한가”입니다. 노드만 바꿔도 해결되는지, 아니면 룰 미스로 DIRECT에 떨어지는지 로그로 먼저 가릅니다. 구독·노드 자체가 불안정하면 도메인을 아무리 정교하게 해도 스피너는 남습니다.

Clash는 규칙별 적중을 텍스트로 남겨 재현에 강하고, 팀 위키에 “이 목록은 어떤 관측에서 왔는지”를 적어 두면 온콜이 짧아집니다. 규칙 프로바이더 URL이 갱신 실패하면 어제까지 되던 CDN 줄이 오늘 빠질 수 있으니, 구독 갱신과 같은 축으로 점검하세요.

관측 우선: 예시 DOMAIN-SUFFIX

아래는 형식 예시입니다. 실제 프로필에서는 DevTools·연결 로그에 나온 호스트로 치환하고, proxy-groups 이름은 팀 규칙에 맞게 바꿉니다. 주석은 영어로 둡니다.

Illustrative YAML fragment

proxy-groups:
  - name: NOTION
    type: select
    proxies: [NODE-A, NODE-B, DIRECT]

rules:
  - DOMAIN-SUFFIX,notion.so,NOTION
  - DOMAIN-SUFFIX,notion.site,NOTION
  - DOMAIN-SUFFIX,makenotion.com,NOTION
  # Replace with hostnames captured from your session, e.g.:
  # - DOMAIN,xxxx.cloudfront.net,NOTION
  # - DOMAIN,api-xxx.execute-api.region.amazonaws.com,NOTION
  # Avoid overly broad AWS keywords unless you accept side effects.
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

GEOIP,KR,DIRECT는 예시이며, 거주·회선·회사 정책에 맞게 조정합니다. 광범위한 DOMAIN-SUFFIX,amazonaws.com는 다른 SaaS·CLI까지 끌어올 수 있어 신중해야 합니다.

RULE-SET·GEOIP 순서

원격 RULE-SET·GEOIP 블록이 위에 있으면, 아래쪽에 둔 Notion 전용 DOMAIN이 아예 실행되지 않습니다. 규칙 모범대로 “위에서 아래로 먼저 이긴다”를 전제로, (1) 제품 관측 규칙, (2) 신뢰하는 지역/측정, (3) 공용 원격 세트, (4) MATCH 순으로 읽기 쉽게 쌓습니다. RULE-SET이 404·인증 실패로 비어 있으면 조용히 통째로 빠지므로, 갱신 실패 알림을 습관화하세요.

팀에서 공유하는 커뮤니티 규칙 세트를 쓰더라도, Notion·AWS 조합은 업데이트 주기에 따라 빈칸이 생깁니다. 로컬 prepend-rules나 소규모 rule-providers로 “우리 관측 덩어리”를 앞에 두면 회복력이 좋아집니다.

DNS·fake-ip·TUN으로 교차 검증

fake-ip와 실제 해석이 어긋나면 “이름은 풀렸는데 TCP가 안 붙는” 현상이 납니다. Meta DNS의 fake-ip-filter에 메인 도메인·관측된 CDN 호스트를 넣고, nameserver·fallback이 규칙 엔진과 같은 결론을 내는지 확인합니다. 라우터 DoH·OS DNS가 동시에 켜져 있으면 우선순위 싸움이 나므로, 변경은 한 축씩 합니다.

검증 루틴은 (1) TUN ON/OFF, (2) 시스템 프록시만, (3) 브라우저만의 세 가지 중 둘을 골라 A/B하고, 각각에서 연결 로그의 도메인 분류 결과를 비교합니다. 캐시가 의심되면 앱 재시동·문서 강력 새로고침으로 세션을 나눕니다(개인정보·로그아웃에 주의).

준수·팀·캠퍼스

⚠ 알림: 이 글은 합법이며 조직/학교/국가/서비스 약관이 허용하는 망·계정 전제의 라우팅 위생을 다룹니다. 무단 우회·보안장치 무력화를 돕는 내용이 아닙니다.

사내 프록시·SSL 가시성·분할 터널이 있으면 개인 YAML만으로는 재현이 어렵습니다. IT 승인 하에 NOTION 규칙 덩어리를 위키에 문서화하고, 기업 VPN과 Clash를 동시에 쓸 때 금지된 이중 터널이 없는지 확인합니다.

체크리스트

  1. 네트워크 탭·연결 로그에서 notion·makenotion·amazonaws·cloudfront 등 SNI를 한 목록으로 모은다.
  2. 각 호스트를 NOTION·NOTION_CDN 등 팀이 동의한 의도에 매핑한다.
  3. 규칙 배열에서 RULE-SET·GEOIP가 세밀한 줄을 가로채지 않는지 본다.
  4. DNS·fake-ip·스니핑이 규칙과 같은 출구를 가리키는지 본다.
  5. 웹·데스크톱 앱·백그라운드가 같은 프로필·TUN 상태에서 재현되는지 비교한다.
  6. 필요 시 TLS·노드·구독 갱신을 병행한다.

맺음말

2026년에도 Notion은 위키·태스크·문서 협업의 중심 도구로 남아 있고, 사용자가 겪는 “계속 도는 동기” 불만은 대역이 아니라 출구 불일치·DNS·긴 연결 타임아웃에서 오는 경우가 많습니다. Clash로 notion.so와 함께 관측된 AWS·CDN 호스트를 한 도메인 분류 의도에 묶고, RULE-SET 순서와 TUN·DNS를 맞추면 재현 가능한 방식으로 증상을 줄일 수 있습니다. Figma·Copilot 글의 호스트 목록과 섞지 않고 별도 맵을 유지하는 것이 운영에 유리합니다.

규칙을 텍스트로 남기고 연결마다 적중을 추적할 수 있다는 점에서, 반복 스피너를 줄이려는 팀에게 Clash는 실험과 롤백이 쉬운 편입니다. 정책은 천천히 다듬되, 관측 로그는 짧은 주기로 갱신하는 습관을 권합니다.

→ Clash를 무료로 다운로드하고, Notion·AWS·CDN 도메인 분류를 연결 로그와 맞춰 동기가 덜 끊기는지 확인해 보세요.