워크 무한 로딩: 채널은 뜨는데 첨부·통화 호스트만 느릴 때

Slack의 워크스페이스 UI는 채널 목록과 메시지 스트림을 보여 주지만, 백그라운드에서는 slack.com 세션·CDN 엣지·파일 업로드·알림·호출(huddle)·분석 패턴 문자열까지 수십 종의 호스트가 겹칩니다. app.slack.com이나 브라우저 탭의 첫 페이지만 선택 정책에 넣고, slack-edge(엣지/자산)·slack-files 류·리전 접미사가 포함된 업로드 URL이 다른 출구나 DIRECT로 떨어지면, 한 화면 안에서 요청 순서만 느려져 “항상 같은 자리만 멈춤·스피너만 돎”처럼 보입니다. 규칙 라우팅 모범에 나온 대로 규칙 적중 순서를 기록하면서, 연결 로그에 찍힌 도메인·SNI를 우선 목록화하는 것이 timeout·TLS를 노드 품질만 의심하지 않도록 만듭니다.

크로스보더 팀에선 회사 SSO·허브에서 이미 프록시를 두는 경우도 있어, 사용자 PC에 깐 Clash와 겹치면 이중 종단이 됩니다. TUN 모드 전체 차단과 “브라우저만 프록시”를 바꿀 때 증상이 달라지는지 A/B해서, 증상이 나오는 플랫폼만 고정해야 합니다(웹 vs 데스크톱 전용 빌드).

ℹ 세 줄 정리: (1) DevTools 또는 데스크톱 앱 디버거가 있다면 네트워크 패널과 Clash 연결 패널에 동일 시각 레이블을 남긴다. (2) 실제 접속 문자열 중 slack·edge·파일 업로드 FQDN·드물게 노출되는 Splunk 문자열 패턴까지 날짜와 함께 표로 적는다. (3) fake-ip·Meta DNS가 규칙 엔진과 같은 종단 선택을 하는지 교차 검증한다.

Discord·Notion 같은 협업 글과 다른가

채널형 협업은 겉 패키지가 비슷해 보여도 종단 세트가 다릅니다. Discord는 보이스 인프라와 CDN 축에 무게가 있고, Notion은 지식 페이지와 AWS·엣지 API가 깊습니다. Microsoft 365·조직별 Teams 레이턴시 이슈는 office.com·엔터프라이즈 종단 묶음이 다른 비중이라, 해당 글의 호스트 블록을 그대로 Slack에 적용하면 빈 규칙 칸과 잘못된 적중이 많아집니다. 제품별로 “우리 세션 로그 기준 목록”을 따로 들고 있는 편이 운영적으로 안전합니다.

업로드·대용량 정적 객체가 많은 채널이라면 대용량 CDN 사례처럼 Hugging Face 분류 글의 접근처럼 “대역 전용 선택 그룹”을 상상할 수 있습니다. 단, 업무 메신저는 채널 상태·알림·세션 표시까지 한 세션에 묶입니다. 과도하게 출구만 쪼개면 레이턴시 패치가 사용자 경험을 엇나을 수 있으니 url-test·fallback 패턴까지 같이 검토해야 합니다.

slack.com·SSO·워크플로 시작 화면

보통 접점은 slack.com 루트·app.slack.com 호스트의 워크스페이스 로더·브랜치 SSO 진입 같은 경로부터입니다. 엔터프라이즈 조직이라면 초대 메일 및 웹 시작에서 IdP 호스트 문자열까지 연결 패널과 비교해야 합니다. 사용자 정의 도메인(구형 워크스페이스·리다이렉트 패턴 포함) 문자열에는 DIRECT가 어색하지 않도록 IT 정책과 맞는지 검토해야 합니다. 제품 업데이트로 하위 문자열 자체가 자주 변경되므로, 커뮤니티 YAML을 무조건 신뢰하지 말고 반드시 본인 워크스페이스를 열었을 때의 도메인을 기준으로 업데이트합니다.

웹 브라우저와 데스크톱 패키지 빌드를 동일 정책으로 비교해야 합니다. OS 방화벽·제로트러스트 에이전트·앱 내부 프록시가 데스크톱에만 깔려 있는 경우 브라우저만 정상이라는 불만 패턴으로 남습니다.클라이언트 종류별로 TUN·시스템 프록시·패킹 범위를 바꿔 보고 차이만 기록하세요.

'slack-edge'·파일·엣지·Splunk 문자열 패턴까지

실무 로그에서는 slack-edge, 파트너 제공 엣지, 서명 업로드 URL이 함께 찍히는 경우가 많습니다. 첨부·이미지·압축 리소스는 짧게 살아 있는 URL로도 열 수 있으며, 패턴 문자열 하나만으로 규칙을 넓히려는 유혹이 생기지만 과도하게 넓은KEYWORD는 다른 업무 페이지까지 끌어오기 쉽습니다. splunk 문자열이 도메인에 포함된 업로드 또는 관측·분석 패턴 문자열 같은 경우도 보고되어 있으며, 문자열 패턴이라고 해서 무조건 DOMAIN-KEYWORD,splunk로 붙들면 동일 문자열 세그먼트를 쓴 비업무 페이지까지 포함됩니다. 따라서 같은 워크스페이스에서 실제 재현 문자열부터 좁은 접미사 또는 FQDN 하나로 올린 뒤, 반복 패턴만 DOMAIN-SUFFIX로 승격하는 편을 권합니다.

AWS·패스트 대체 엔드포인트(.amazonaws.com 패턴 포함) 문자열 자체가 뜰 수 있으며, 회사 차원에서 같은 리전 문자열 안에 들어있는 다른 IaaS 업무까지 프록시에 합류시키려면 업무 간섭이 큽니다. 그러므로 해당 SaaS 종단 호스트부터 관측된 FQDN으로 좁히는 편을 권합니다. 새 릴리스 분기별로 문자열 차이도 다시 채워야 합니다.

콜(huddle)·브라우저 WebRTC 레이어

음성·소규모 화상(제품 기능명은 릴리스마다 표기 차이 가능)에서는 브라우저의 WebRTC와 별도 업로더·코덱 엔드포인트가 더해져, 순수 HTTP 프록시 가정만으로는 연결이 깨져 보일 수 있습니다. UDP·ICE 후보 때문에 “HTTPS는 되는데 콜 버튼만 계속 깜빡인다” 패턴과 겹치기도 합니다. 브라우저 사용 환경이면 WebRTC 검증 안내의 테스트 절차를 함께 적용하세요. 데스크톱 패키지는 디버깅 패널·로그가 브라우저와 많이 다른 경우가 있으므로 플랫폼 간 차이를 먼저 비교해야 합니다.

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

예시로 SLACK_APP 하나에 메인 페이지·워크 로더·이미지 자산 호스트까지 넣거나, 업로드가 길어지는 회선만 SLACK_CDN으로 나눌 수 있습니다. 핵심은 “동일 채널 사용자 세션에서 기대되는 지연과 지역 문자열 노출을 일치할 수 있는가”입니다. 노드 교체만으로 해결되는지, 아니면 RULE MISS 때문에 DIRECT로 떨어지는지 연결 패널로 먼저 구분해야 합니다. 구독·노드 품질 자체가 흔들리면 레코드 교정만으로 스피너가 줄지 않을 수 있습니다.

규칙 세트를 팀 위키에 버전과 함께 남기면 온콜 업무 시간이 줄고, 외부 RULE_PROVIDER URL이 강제로 깨져 엣지 전용 줄이 빠져도 교체 순서를 빠르게 따라잡을 수 있습니다.

관측 우선 예시 YAML

아래는 형식 예시입니다. 실제 항목은 회사 채널에서 포착한 도메인으로 치환하고, 그룹 이름은 규약에 맞게 바꿉니다. 줄 주석은 영어 규약을 따릅니다.

Illustrative YAML fragment

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

rules:
  - DOMAIN-SUFFIX,slack.com,SLACK
  - DOMAIN-SUFFIX,slack-edge.com,SLACK
  # Paste hostnames captured from YOUR workspace logs, e.g.:
  # - DOMAIN-SUFFIX,slack-files.com,SLACK
  # - DOMAIN,xxxx.cloudfront.net,SLACK
  # Narrow splunk-labelled hosts only after you confirm duplicates:
  # - DOMAIN,target-with-splunk-segment.enterprise.example.net,SLACK
  # Avoid DOMAIN-KEYWORD,splunk alone — it grabs unrelated corp paths.
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

GEOIP,KR,DIRECT는 예시입니다. 거주 지역·근무 회선·사내 규칙 문서를 따로 반영해야 합니다. 지나치게 넓게 잡은 .amazonaws.com 패턴 규칙은 다른 업무용 AWS 접속까지 같이 빨아들일 수 있습니다.

RULE-SET 순서 함정 피하기

원격 RULE-SET이나 범위가 큰 GEOIP 줄이 규칙 목록 상단을 차지하면, 하단의 Slack 전용 도메인 줄이 실행되기 전에 먼저 소비되어 버립니다. 규칙 모범 사례의 “먼저 이긴 규칙이 우선” 원칙에 맞춰 제품별 관측 줄 → 지역 선택 → 커뮤니티 공유 패키지 → MATCH 같은 중복 없는 배열 순서가 필요합니다. rule-provider 다운로드 URL이 인증 예외 또는 403으로 깨져 비어 버리면 해당 RULE-SET이 통째로 빠져 체감 이상 증폭만 될 수 있습니다.

다른 조직 규모를 전제로 한 공통 규칙 패키지만 무조건 신뢰하면 Slack 전용 도메인 갱신이 밀린 빈 목록 상태가 생깁니다. prepend-rules나 소량 rule-providers에 “내 워크 관측에서 실제 확인한 호스트”를 규칙 파일 상단쪽에 깔아 복구력을 올립니다.

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

fake-ip와 원격 리졸버가 같은 결론을 내지 않으면 “이름만 풀렸고 TCP 세션이 끊김”으로 보일 수 있습니다. Meta DNS의 fake-ip-filter에 채널·엣지·파일 업로드에 필요한 호스트 문자열을 함께 넣었는지, nameserver·fallback 순서와 규칙 엔진이 같은 출구를 선택하는지 교차 검증해야 합니다. 라우터 DoH와 OS 설정이 각각 레지스트리 리졸버를 잡아 경쟁하면 원인 분리가 어려우므로 바꿀 때는 변수를 한 번에 하나만 조정합니다.

TUN 켠 상태·켜지 않은 상태·브라우저만 따로 테스트했을 때 증상이 다르면 어떤 경로 레이어만 빠졌는지 추적해야 합니다. 앱 업데이트나 보안 패치를 거칠 때는 한 축만 바꾸고 결과를 확인해 혼선을 줄입니다.

준수·관리형 보안 디바이스

⚠ 알림: 이 글은 합법이며 회사 규칙과 서비스 약관이 허용할 때만 라우팅 표기를 바로잡는 망 관리 위생을 다룹니다. 보안 장치 우회나 정책 위반 행위를 돕지 않습니다.

사내 게이트웨이·TLS 검사·분할 VPN이 존재하면 개인 YAML만으로 증상이 재현되지 않습니다. IT 승인을 받아 SLACK 블록을 위키에 문서화하고, 기업 VPN과 Clash를 동시에 쓸 때 이중 터널이 금지되지 않았는지 반드시 확인합니다.

체크리스트

  1. DevTools 또는 연결 패널에서 slack.com·slack-edge·파일 업로드 FQDN·Splunk 문자열 패턴 같은 SNI 목록을 날짜와 함께 표로 적는다.
  2. 각 호스트를 팀 합의에 따라 SLACK 또는 SLACK_CDN 등 의미 있는 정책 이름에 매핑한다.
  3. 규칙 배열 상단에서 공유 RULE-SET 또는 GEOIP가 세밀한 도메인 규칙을 가로막지 않는지 검토한다.
  4. DNS 설정과 fake-ip, 스니핑이 선택한 출구와 일치하는지 확인한다.
  5. 웹·데스크톱 앱·백그라운드 업데이터가 같은 Clash 프로필에서 증상이 재현되는지 비교한다.
  6. 문제 지속 시 TLS, 노드, 구독 갱신을 함께 점검한다.

맺음말

2026년에도 크로스보더 협업을 위한 클라우드 메신저는 여전히 핵심 도구입니다. 채널은 뜨는데 파일·통화 버튼만 멈추는 증상은 순수 회선 속도 때문만이 아니라 출구 불일치, DNS, WebSocket 같은 긴 세션 타임아웃에서 많이 발생합니다. Clash로 slack.com과 로그상 관측한 엣지·CDN·관측용 호스트 문자열 패턴까지 한 번에 같은 RULE-SET 의도로 묶고, 순서 덫을 피하며 DNS·TUN을 맞추면 무한 회전 상태를 줄이기 쉬워집니다. Discord 또는 Copilot 기사의 규칙 목록과 섞어 쓰지 말고 별도 매트릭스를 유지할 것을 권장합니다.

규칙을 사람이 읽기 쉬운 텍스트로 남기고 적중 로그까지 추적할 수 있어, 반복 스피너를 줄이려는 팀에 Clash 방식은 실험 비용 대비 회수가 높습니다. 정책은 천천히 손보고, 관측 로그 목록만 짧은 주기로 갱신합니다.

→ Clash를 무료로 다운로드하고, Slack·CDN·파일 업로드를 연결 패널과 맞춰 워크스페이스가 덜 버벅거리게 확인해 보세요.