Notion 동기 지연? Clash 분류·WS·DNS (2026)

증상: 동기화가 느리거나 계속 돌 때 무엇을 의심할까

대표적인 패턴은 세 가지입니다. 첫째, 페이지 본문은 열리는데 상단 동기 표시만 길게 유지되고, 새 블록을 쳐도 서버 반영이 지연되는 경우입니다. 둘째, 웹에서는 나아졌다가 데스크톱 앱에서만 자주 멈추거나 그 반대인 경우로, OS 시스템 프록시와 앱 자체 스택이 갈라진 신호로 읽을 수 있습니다. 셋째, 특정 공유기·회사망·국제 회선에서만 재현되고, 스마트폰 테더링으로 바꾸면 증상이 사라지는 패턴입니다. 공통점은 한 번의 클릭 뒤에도 수십 개의 요청이 동시에 돌아가고, 그중 상당수가 HTTPS 위의 REST뿐 아니라 WebSocket(wss)처럼 장기 연결을 유지한다는 점입니다. 장기 연결은 한 번 끊기면 클라이언트가 재수립·재시도를 반복하기 때문에, 체감으로는 “한참 로딩”이나 “갑자기 동기가 멈춤”으로 나타나기 쉽습니다.

Clash 관점에서는 “어떤 호스트가 어떤 정책 그룹으로 나갔는지”가 먼저 선명해야 합니다. 넓은 GEOIP·거대 RULE-SET 한 줄이 먼저 매칭되면, 사용자가 아래쪽에 두었던 Notion 전용 규칙은 실행되지 않을 수 있습니다. 또한 TCP로 보이는 본문 편집과 wss로 이어지는 실시간 스트림이 서로 다른 IP·노드·DNS 답을 보면, 앱 입장에서는 세션이 엇갈립니다. 따라서 일반적인 “속도 올리기” 문구가 아니라, 규칙 적중 로그 → DNS 응답 → 실제 아웃바운드를 같은 축에서 읽는 습관이 필요합니다.

이 글은 “인터넷 가속” 글이 아닙니다

트래픽을 무조건 한 노드에 몰아 세계 최고 체감 지연을 노리는 접근은 이 글의 범위 밖입니다. 여기서 말하는 안정화는 협업 SaaS가 요구하는 일관된 경로, 즉 동일 계정·동일 기기에서 문서 메타데이터와 실시간 동기 채널이 서로 모순되지 않게 만드는 데 가깝습니다. 회사 규정·개인정보·클라우드 거점 정책을 위반하는 우회를 조장하지 않으며, 합법적인 네트워크 환경에서의 트러블슈팅을 전제로 합니다.

1어떤 호스트가 Notion 동기·실시간에 관여하나

고정된 “영구 정답 목록”보다 본인 환경에서 관측한 이름을 우선합니다. 브라우저 개발자 도구의 Network 탭에서 notion으로 필터링하고, WS·Fetch·EventSource 항목을 함께 봅니다. 흔히 notion.so·www.notion.so 접두의 HTTPS와, 동일 브랜드 아래 wss 연결이 동시에 존재합니다. 공개된 행사·CDN·파일 업로드용 호스트가 더해지면 한 화면만 보아도 이름이 여럿입니다. 앱 버전은 웹과 엔드포인트 묶음이 다를 수 있으므로 “웹에서 고른 규칙을 앱에 그대로 복사”하기 전에 앱 쪽 로그를 한 번 더 확인하는 편이 안전합니다.

이렇게 모은 목록을 가지고 Clash 클라이언트의 연결·로그 화면과 대조합니다. 연결 한 줄마다 도메인 또는 IP, 체인, 정책이 어떻게 찍히는지 확인하면, “왜 wss만 다른 출구를 보는가” 같은 가설을 빠르게 좁힐 수 있습니다. 이름이 IP로만 찍힌다면 아래 Sniffer 절과 같이 읽어야 합니다.

WebSocket(장기 연결)이 민감한 이유

브라우저와 서버는 실시간 업데이트를 WebSocket으로 주고받는 경우가 많습니다. TCP 기반이지만, 연결이 수 분~수 시간 유지되고 중간에 프록시·NAT·회선 품질에 따라 조용히 끊겼다가 재연결되는 특성이 있습니다. 한 번의 짧은 HTTP 실패보다 디버깅이 어려운 이유는, 사용자에게는 그저 “동기 아이콘이 돈다”로만 보이기 때문입니다. 분류 규칙이 중도에 바뀌거나(노드 자동 전환), DNS만 다른 서버를 가리키면, 클라이언트는 같은 페이지라도 서로 다른 백엔드 뷰를 섞어 보는 상황에 가까워질 수 있습니다.

요약: 동기화 문제를 다룰 때는 “첫 화면이 열렸는지”만 볼 것이 아니라, wss가 어떤 정책 그룹으로 이어졌는지까지 한 세트로 봅니다.

2분류 규칙 최소 예시(illustration)

아래는 설명용 스케치입니다. PROXY 자리에는 구독에 정의된 실제 그룹 이름을 넣고, 이미 상단에 GEOIP·MATCH가 있다면 순서를 함께 조정하세요. 엔드포인트는 제품 업데이트로 바뀔 수 있으니, 본문의 접미사는 출발점으로만 보고 관측으로 보완합니다.

# Illustration — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,notion.so,PROXY
  - DOMAIN-SUFFIX,notion.site,PROXY
  - MATCH,DIRECT

DOMAIN-SUFFIX는 같은 접미사 아래 여러 서브도메인을 한 번에 덮는 편이 수월합니다. 반대로 너무 넓은 접미사를 쓰면 무관 트래픽까지 같은 노드로 몰릴 수 있으니, 로그에 자주 뜨는 이름부터 시작해 점진적으로 좁히는 것이 안전합니다. 유지보수를 위해 Rule Provider로 묶어 두면 나중에 엔드포인트가 늘어도 파일 하나만 갈아 끼울 수 있습니다. 대규모 규칙 세트 선택 기준은 ACL4SSR·rule provider 비교 글을 참고하세요.

규칙 순서와 “첫 매칭이 전부”인 점

Clash 계열은 위에서 아래로 읽으며 처음 걸린 줄이 결론입니다. 그 위에 글로벌 한 줄이 먼저 매칭되면 아래의 Notion 전용 줄은 사실상 죽은 코드가 됩니다. “파일엔 notion 줄이 있는데 로그엔 다른 정책만 찍힌다”면 이 순서부터 의심합니다. 국내 직결(DIRECT)이 더 낫다고 판단되는 환경이라면, 같은 접미사를 DIRECT로 두되 문제 재현 여부를 다시 확인하는 편이 낫습니다. 핵심은 본인 회선에서 실제로 나은 쪽을 로그로 증명하는 것입니다.

3Sniffer: HTTPS·wss가 IP로만 보일 때

로그에 IP만 남고 도메인이 비면 DOMAIN 규칙이 자주 빗나갑니다. Clash Meta(Mihomo)의 Sniffer는 TLS SNI·HTTP/2 등에서 호스트를 복원해 매칭을 안정화합니다. 설정 흐름·주의점은 Clash Meta Sniffer 가이드에 정리되어 있으며, Notion처럼 장기 세션이 많은 앱일수록 “이름을 볼 수 있는지”가 규칙 품질과 직결됩니다.

4DNS·FakeIP·DoH를 규칙과 맞추기

FakeIP를 쓰는 프로필에서는 클라이언트 내부의 IP 풀과 실제 터널의 목적지가 미묘하게 어긋나 규칙 매칭이 흔들릴 수 있습니다. DoH를 OS나 브라우저에 별도로 켜 두면 “같은 이름인데 응답 경로가 다르다”는 상황도 생깁니다. 단계별 체크리스트와 설정 패턴은 Meta 코어 DNS 유출 방지 가이드를 먼저 따르고, 변경은 한 겹씩만 적용해 재현 실험을 반복하는 편이 디버깅 비용을 줄입니다.

5TUN과 데스크톱 앱: 캡처 범위 맞추기

브라우저만 시스템 프록시를 따르고, Notion Electron 앱은 다른 경로로 나가면 동기 상태가 플랫폼마다 제각각일 수 있습니다. 이때 TUN은 시스템 라우팅에 가깝게 개입해 “누락 트래픽”을 규칙 표 안으로 끌어오는 데 유리합니다. Windows에서 가상 어댑터·권한까지 맞추려면 Clash Verge Rev TUN 모드 가이드를, 설치 자체부터 필요하면 Windows Clash 설치 글을 함께 보는 순서가 안전합니다. UDP 음성까지 겹치는 메신저 시나리오는 Discord·UDP·TUN 글과 대조해 읽으면, TCP·장기 연결과 UDP 실시간의 차이를 정리하기 쉽습니다.

주의: 사내 VPN·엔드포인트 보안·공유기 DNS 가로채기가 동시에 켜 있으면 Clash만 고쳐도 증상이 남을 수 있습니다. 단일 경로로 줄인 뒤 다시 재현해 보세요.

노드 품질·자동 전환과 장기 연결

규칙이 맞아도 출구 노드가 불안정하면 WebSocket은 중간에 끊깁니다. latency가 낮아 보여도 손실·왕복 지터가 크면 체감 동기 지연은 커집니다. url-test·fallback류 정책 그룹으로 일정 조건에서 노드를 바꾸는 구성은 편리하지만, 전환 순간 기존 wss 세션이 함께 재수립되어야 하므로, 과도한 잦은 스위칭은 오히려 “계속 로딩”처럼 보일 수 있습니다. 자동 전환 임계값과 테스트 간격은 보수적으로 두고, 먼저 규칙·DNS가 안정일 때만 세밀하게 조정하는 편이 안전합니다.

6검증 순서

Network·클라이언트 로그에서 Notion 관련 호스트와 정책 이름을 목록으로 남깁니다.
분류 규칙을 최소 세트로 올린 뒤, 같은 동작을 반복해 적중이 바뀌었는지 확인합니다.
DNS·FakeIP·스니퍼를 한 번에 건드리지 않고 한 층씩 맞춥니다.
웹과 데스크톱 앱을 번갈아 시험해 캡처 범위(시스템 프록시 vs TUN) 차이를 비교합니다.
다른 회선(테더링 등)에서 같은 절차를 밟아 “규칙 문제인지 회선·노드 문제인지”를 나눕니다.

계정·문서 내용은 로그에 남지 않게 주의하고, 회사 자산을 다루는 경우 IT 정책을 우선합니다.

오픈소스 정보와 설치 패키지

Mihomo와 GUI 포크의 라이선스·이슈는 GitHub에서 확인할 수 있지만, 클라이언트 설치 파일의 주 경로로는 이 사이트의 Clash 다운로드 페이지를 권장합니다. 소스는 신뢰 확인용으로 두고 업무용 업데이트는 허브에 맞추면 혼선이 줄어듭니다. 전체 옵션 지도는 문서·설정 허브 목차와도 연결됩니다.

맺음말

Notion의 동기 지연·무한 로딩은 종종 단일 호스트의 지연이 아니라, 문서·실시간·부가 API가 한 화면에서 동시에 돌아가며 서로 다른 네트워크 조건을 만날 때 크게 드러납니다. Clash로 이를 다루는 핵심은 감으로 노드를 바꾸는 것이 아니라, 어떤 이름이 어떤 정책을 탔는지 로그로 확인하고, DNS·FakeIP·Sniffer·TUN을 같은 전제로 정렬하는 일입니다. 이 틀은 다른 협업 SaaS·장기 WebSocket 앱에도 그대로 이식할 수 있습니다.

다른 클라이언트에 비해 Clash Meta 계열은 연결 로그와 정책 이름 대응이 읽기 쉬워, 체감상의 “가끔만 안 된다”를 관측 가능한 사실로 바꾸기에 유리합니다. 규칙을 한 번 정리해 두면 이후 유사 증상 대응 시간도 줄어듭니다.

→ Clash를 무료로 다운로드하고, Notion 동기·WebSocket 경로를 한 프로필에서 점검해 보세요

Notion 동기화가 계속 로딩일 때: Clash 분류 규칙과 WebSocket·DNS로 연결 안정화 (2026)