노션 워크스페이스가 계속 로딩·동기 불안정이라면 CDN과 API부터【2026 Clash 분류 전략】

워크스페이스 무한 로딩이 생기는 구조적 이유

브라우저 하나로 보이는 노션 탭 안에서는 사실 많은 종류의 HTTP 요청과 지속형 연결(실시간 협업)이 동시에 돌아갑니다. 워크스페이스 초기 진입 때는 문서 렌더 셸만이 아니라 블록 메타를 불러 오는 백엔드 API 호출, 페이지 아이콘·내장 차트 스크립트 같은 정적 패키지, 그리고 멀티 커서·댓글 스트림에 기대는 장기 채널까지 엮입니다. 사용자 PC에 설치된 Clash가 Rule 모드로 각 호스트 이름마다 다른 분류 규칙 출구를 선택한다면 일부 요청만 회사 회선 또는 국내 DIRECT로 새고 다른 요청은 불안정한 해외 노드로 나가는 식으로 섞여 패킷 순서가 어긋납니다. 결과는 UI 껍데기만 열린 채 속 데이터가 채워지지 않거나, 저장 상태 알림만 반복 깜박거리거나, 간헐적으로 “동기화 중” 상태가 길게 남습니다.

도메인 측면에서 *.notion.so 같은 와일드 패턴 축은 업데이트와 함께 바뀔 수 있습니다. 오래된 YAML 스니펫을 그대로 붙여 넣었다가 일부 새 호스트가 빠지면 “어제까지 됐는데 새벽 배포 이후 갑자기” 형태 장애로 보입니다. 한국에서는 본사·재택 간 이동, VPN 토글, DNS 캐시가 교차하는 일이 흔하므로 시간대별로 한 번 더 재현 테스트를 하는 것만으로 원인 분기가 줄어듭니다.

• 정적·CDN 채널이 다른 출구면 아이콘·내장 패널·일부 차트 레이어만 비어 있습니다.
• REST·Graph 스타일 API가 끊기면 저장 상태가 실패 카운터만 올리거나 권한 메시지를 반복합니다.
• 실시간 채널만 느려지면 본인 타이핑은 되는데 협업 상대 블록 위치 업데이트가 밀린다처럼 보입니다.

트래픽을 세 축으로 나누면 장애 복구 속도가 빨라진다

증상 문자열보다 먼저 “어떤 축이 깨졌나” 관점으로 나누면 정책 이름도 일관적으로 짓기 쉽습니다.

축	역할	사용자가 느끼는 힌트
앱·문서 셸	notion.so 중심 HTML·메인 번들 로드·로그인 루프	초기화 직후 흰 화면 또는 무한 리다이렉트 루프
정적 CDN	*.notion.so 패턴처럼 붙어 있는 에지 패키지	블록 속 위젯·아이콘·내장 패널이 비어 있습니다
API·메타	페이지 트리, 권한, 첨부, 자동 저장	저장 상태 표시가 빨간색 또는 재시도 루프

이미 회사에서 Microsoft 365·Copilot 같은 사무 SaaS 패턴 라우팅을 쓴다면 노션 블록을 같은 YAML에 추가할 때 M365 규칙 세트와 순서 충돌이 없는지 함께 봐야 합니다. 디자인 계열이라면 같은 다축 패턴 논리를 깐 Figma·CDN 사례 글도 교차 참고하면 패턴 학습 속도가 납니다.

notion.so 패턴 호스트 묶음을 관측한 뒤 정책 그룹에 넣기

네트워크 패널에 적힌 호스트 문자열 목록부터 붙여 보관해 두세요. 접두 패턴 규칙은 넓게 잡아 두었다가 업데이트 소식 들을 때마다 좁혀 가면 유지관리 여유가 있습니다.

notion.site는 외부에 공유한 퍼블릭 페이지 때문에 내부 위키와 외부 링크를 오가는 팀에서는 별도 도메인이지만, 기능적으로 같은 노션 생태로 간주하고 notion.so 줄기와 같은 정책 그룹에 두는 편이 안전합니다. rule-provider 형태 원격 규칙 목록과 광고 차단 규칙을 동시에 쌓았다면, 협업 SaaS 정상 자산 요청까지 우연히 REJECT 되지 않았는지 정기 확인이 필요합니다.

분류 규칙을 쓰기 전 전략 그룹과 노드를 먼저 정한다

Clash 규칙 테이블은 결국 패킷이 탈 목적 프록시만 고르고, 속도와 안정도는 proxy-groups 구조에서 크게 결정합니다. 많은 구독 템플릿이 짧은 url-test 간격만 달아 두면 노드 교체 순간마다 실시간 WebSocket이 깨져 보입니다. 그럴 때는 fallback이나 더 안정적인 단일 노드 실험이 낫습니다. 한국에서는 국내 사무 시스템은 DIRECT로 두고 노션처럼 해외 에지 의존도가 큰 줄기만 같은 전략 그룹에 넣어 RTT 과증폭을 줄이는 패턴을 자주 택합니다.

구독 YAML에 거대한 MATCH,PROXY처럼 광범한 마지막 블록이 깔려 있다면 노션용 suffix 라인은 그보다 반드시 위쪽에 두세요. 그렇지 않으면 최종 블록이 먼저 적용되어 노션 트래픽이 다른 출구로 새어 반쪽 로딩만 반복됩니다.

규칙 순서 YAML 스케치 이후 즉시 테스트

샘플이므로 정책 그룹 이름은 자신의 구독과 맞게 다시 채워 넣으세요. 온라인에 퍼진 긴 문자열 패키지를 그대로 붙여 넣기보다 개발자 도구 패널에 관측한 호스트 줄기부터 한 줄씩 기록하는 방식이 2026년 이후 패치 환경에서도 더 안전합니다.

# Illustrative snippet — rename policy groups; observe hostnames locally
rules:
  - DOMAIN-SUFFIX,notion.so,NOTION-STABLE
  - DOMAIN-SUFFIX,notion.site,NOTION-STABLE
  # Public pages or legacy redirects spotted in logs
  - DOMAIN-SUFFIX,notion.com,NOTION-STABLE
  - DOMAIN-KEYWORD,notion,NOTION-STABLE       # Narrow if false positives show up for other brands
  - GEOIP,KR,DIRECT                         # Tune or remove if roaming abroad
  - MATCH,GLOBAL                            # 또는 구독 패키지의 최종 선택 그룹명

노션 첨부나 업로드가 클라우드 스토리지 호스트까지 이어질 때 네트워크 패널에 같은 호스트가 줄지어 보이기도 합니다. 패널에 찍힌 줄기를 좁힌 뒤 필요한 경우에만 해당 suffix를 규칙에 더하세요. 관측 없이 AWS처럼 광범위한 suffix 전체를 DIRECT로 박아 두었다가 다른 업무 SaaS API가 깨지는 회귀 장애는 흔하니 과감히 피해야 합니다.

DNS와 fake-ip, 노드를 한 묶음으로 다시 검증하기

같은 도메인 이름이라도 DNS가 ISP 쪽으로만 가느냐 Clash 내부 resolver까지 거치느냐에 따라 엣지 선택이 바뀌며 체감 지연도 달라집니다. fake-ip 모드를 쓰면 브라우저 패널에 표시되는 IP 주소와 Clash 라우팅 로그의 목적지 정보가 크게 차이 나는 것처럼 보일 때가 있습니다. 실제 패킷은 정상이라도 진단 과정만 혼란스럽게 느껴지면 DNS·fake-ip 점검 글에서 이름 해석 순서를 정리하고 노션 규칙을 손보는 편이 낫습니다.

Windows에서 브라우저 전용 플러그인에만 프록시를 걸거나 TUN과 시스템 프록시를 교차 테스트하는 과정에서는 캡처 지점 순서 때문에 혼선이 생기기 쉽습니다. Clash for Windows 세팅 가이드를 읽어 Rule 모드·TUN의 차이를 정리한 다음 실제 패킷이 통과할 경로를 먼저 확정합니다.

데스크톱 앱과 브라우저가 동시에 열린 경우

macOS·Windows 네이티브 노션은 브라우저 프로필과 TLS 설정, 로컬 DNS 캐시 위치가 달라 한쪽 채널만 느린 증상이 나면 설치형 앱 쪽부터 살피는 편이 원인 범위를 빠르게 좁힙니다. TUN과 시스템 프록시를 함께 쓸 때는 순서가 꼬이면 패킷이 우회되어야 할 경로와 실제 패킷이 어긋나므로 Connection 로그와 네트워크 패널 캡처를 교차 확인해야 합니다.

코드 작성 IDE와 회의 노트를 같은 날 같은 네트워크 줄기에서 묶어두는 원격 근무 팀은 워크스페이스 지연이 교차 줄기로 전파되어 체감이 큽니다. Clash·Cursor 개발 가이드에서 정리된 다중 SaaS 출구 줄기와 교차 테스트하는 습관을 같이 들이세요.

사내 직통 트래픽과 노션 전용 출구를 나누기

국내 카드 단말이나 사내 SSO는 직통이 편하고, 노션처럼 해외 협업 SaaS만 별도 노드로 빼는 패턴이 가장 많이 씁니다. 이때 GEOIP 블록이나 지나치게 넓은 규칙이 노션 suffix보다 더 위쪽에 깔려 있으면 회사에서는 되지만 집에서는 실패처럼 보여 원인만 흐릿하게 만듭니다.

대규모 기업에서는 사내 전용 보안 프로그램과 개인 장비 프록시를 동시에 켜지 못하도록 하는 정책이 흔합니다. 허용된 테스트 PC 또는 별도 가상 업무 블루프린트를 받은 뒤 계정 역할과 결과 공유 채널을 문서로 맞춰야 하는 경우가 많아, 개인 사용자 가이드를 그대로 복사하기 어려울 수 있습니다. 재택 환경에서는 가정 공유기 QoS나 운영체제 절전 모드 때문에 지터가 커져 노션처럼 실시간성이 높은 앱 증상이 커 보일 수 있으므로 가능하면 유선 링크에서 동일 테스트를 한 번더 재현해야 합니다.

1. 국내 카드 단말, 사내 업무 포털, SSO는 우선적으로 DIRECT에 두기.
2. 관측한 notion.so·notion.site와 *.notion.so 호스트 줄기는 같은 정책 그룹에 묶기.
3. Connection 로그에 정책 이름과 목적 호스트 이름을 줄 단위로 기록하기.
4. 노드를 바꾼 직후 WebSocket이 순간 끊기지 않는지 짧게 반복 확인.
5. 동료 계정과 다른 기기에서 동기·저장까지 교차 검증.

평균 지연보다 지터와 재연결 루프를 먼저 보라

네트워크 품질 패널에 나오는 평균 왕복 지연은 낮은데 순간마다 패킷이 들쭉날쭉한 노드를 선택하면 TLS 완료와 정적 패키지 요청이 순차 대기로 쌓이면서 화면 골격만 열렸는데 속 데이터가 계속 회전하는 증상이 나타납니다. 노션처럼 호스트 이름이 순서 블록으로 이어지는 SaaS에서는 지터 하나가 연속 요청 묶음 처리 흐름으로 전파되어 체감 첫 화면 체류 시간까지 잡음으로 바뀌기 쉽습니다. 벤더가 제공하는 단일 속도 테스트 수치만으로는 부족하니 Connection 로그에 찍힌 재시도 카운터나 세션 교체 이벤트를 같은 타임라인에서 읽어야 운영 수준 근거를 확보합니다.

팀 테스트는 새벽이나 주말 짧은 타임 창구를 만들어 같은 단말에서 노드를 바꿔 가며 순차 검증해야 동료 업무 흐름을 덜 흔듭니다. 한국 회선이라고 해서 무조건 국내 인접 노드가 최적인 것만은 아니고, 고객·파트너 조직이 다른 대륙에 몰려 있다면 해당 대역에 맞춘 출구 선택이 저장 일관성에 도움이 될 때도 있습니다. 회사 회선 테스트와 개인 장비 테스트는 파일 이름이나 회의 노트 표 제목으로 구분해야 감사·보안 대응에서도 혼선이 줄어듭니다.

증상 재현 순간에는 어느 화면이 멈춰 있는지 브라우저 주소, 데이터베이스 블록, 편집기 커서 위치와 함께 WebSocket 존재 여부, 선택된 정책 이름을 표 한 줄 또는 텍스트 한 줄 형태로 쌓아 두세요. 이후 바꿔 본 DNS 모드 조합까지 날짜와 함께 붙이면 팀과 공유하거나 나중에 이전 상태로 되돌릴 때 디버깅 시간이 크게 줄어듭니다.

FAQ

헤더는 뜨는데 테이블·데이터베이스만 무한 로딩일 때 볼 곳은?

정적 자산과 백엔드 API가 서로 다른 프록시 출구를 타거나, 회사 SSL 검사 장비와 경로가 어긋날 때 비슷하게 보입니다. 개발자 도구 네트워크 탭과 Clash Connection 로그를 나란히 펼쳐 정책 이름이 같은지 먼저 비교하세요.

노드 자동 전환이 잦으면 실시간 협업이 왜 끊기나요?

url-test 주기가 매우 짧으면 WebSocket이 완전히 닫히기 전 노드가 바뀌며 끊깁니다. 테스트 간격과 tolerance를 여유 있게 잡거나 안정적인 단일 노드와 fallback 전략을 조합해 실험해 보세요.

회사 단말에 루트 인증서가 설치되어 있으면 어떻게 하나요?

법인 장비에서는 보안팀 방침을 따르세요. 개인 단말과 회사 회선 테스트를 구분해야 Connection 로그를 읽어도 혼선을 줄입니다.

실무 체크리스트

마무리: 운영·감사까지 고려한 Clash 활용 포인트

브라우저 확장만으로 우회 노드를 교체하는 패턴은 처음 접할 때 간단하지만, 노션처럼 앱 컨테이너·CDN 패키지·백엔드 API 줄기가 번갈아 열리는 서비스를 여러 디바이스에서 묶어두려면 규칙과 감사 항목이 기하급수로 늘어납니다. 특히 업무 회선 회사와 재택 줄을 오가며 프록시 토글을 수동 장난감처럼 두드리면 어느 축부터 다시 테스트해야 할지 순서 디버깅만 반복하게 됩니다. 보안 책임자와 업무 책임자가 동시에 들여다볼 출구 줄기 다이어그램이라도 간단히 맞춰 두면 같은 증상이 와도 이 글의 순서처럼 교차 테스트가 가능해집니다.

Clash 같은 Rule 기반 클라이언트는 순서 블록이 분명해서 Connection 로그로 정책 이름과 목적 호스트를 한 줄씩 대조하기 쉽고, 노션 줄기와 디자인·코드 작성 도구 줄기처럼 그룹을 나누어 추적 가능합니다. 벤더가 제공하는 빌트인 우회 패키지만 믿는 방식보다 업데이트 주기별로 패킷 경로 줄기를 줄일 수 있는 점 역시 차이점입니다.

한 번 순서 블록을 확정했다면 같은 전략 이름을 다른 팀과 공유하거나 교육 시간을 줄여 운영 집약도를 낮출 수 있습니다. 운영자 맞춤형 실험 순환을 돌릴 수 있다는 점은 협업 SaaS가 늘어나는 2026년 이후에도 여전히 중요한 축입니다.

Clash 공식 페이지에서 클라이언트를 내려받고 Connection 로그를 열어 이 글의 규칙 스케치를 그대로 실험해 보세요.