Slack: 회사 프록시 뒤에서 뜨는 "Slack cannot connect"와 회색 "Last updated…" 띠
안녕하세요, BlueByte입니다. Slack이 열리고 채널 목록까지 뜨는데, 잠시 뒤 회색 띠에 Last updated less than a minute ago…가 뜨며 새 메시지가 오지 않거나, 아예 Slack cannot connect.와 Restart Slack 버튼으로 포기해 버립니다. 같은 PC의 브라우저는 slack.com에 멀쩡히 들어갑니다. 회사 네트워크에서 이 패턴은 거의 언제나 같습니다. Slack의 HTTP 쪽은 열려 있고 WebSocket 쪽이 막혀 있는 것입니다. 오늘은 Slack이 왜 두 번째 종류의 연결을 필요로 하는지, 회사 네트워크에서 그것을 끊는 네 가지, 어느 것인지 보여 주는 curl 프로브 두 개, 원인별 해결, 그리고 다음 프록시 변경이 Slack을 다시 끊지 않게 하는 방법까지 하나씩 짚어보겠습니다.
Slack에 HTTPS만이 아니라 WebSocket이 필요한 이유
채널·히스토리·파일을 불러오는 것은 *.slack.com과 Slack이 관리자용으로 공개한 에셋 도메인으로 가는 평범한 HTTPS입니다. 실시간 전달 — 새 메시지, 입력 중 표시, 접속 상태 — 은 지속 연결되는 WebSocket을 타는데, Slack 관리자 안내에 따르면 이 연결은 443 포트로 Slack이 이름을 밝힌 세 호스트 — wss-primary.slack.com, wss-backup.slack.com, wss-mobile.slack.com — 에 붙습니다. primary·예비·모바일이라는 역할은 이름을 보고 읽은 것이고, Slack은 역할 없이 목록만 적어 두었습니다. WebSocket은 Upgrade: websocket을 실은 HTTPS 요청으로 시작하고, 서버가 101 Switching Protocols로 답하면 그 연결이 몇 시간이고 열린 채 유지됩니다. 그 사이에 요청-응답 HTTP만 아는 장비가 있거나, TLS를 끊었다가 다시 암호화하면서 upgrade를 이해하지 못하는 장비가 있으면, Slack은 웹 계층은 살아 있고 메시지 스트림은 죽은 상태가 됩니다. 회색 띠가 알리는 것이 바로 이것이고, Slack 자체 문구로는 채널과 DM의 새 메시지를 자동으로 받지 못하게 된다는 뜻입니다.
회사 네트워크가 이 연결을 끊는 네 가지 방식
프록시나 방화벽이 WebSocket을 통과시키지 않습니다. 일부 웹 프록시는 Upgrade 헤더를 떼어 내거나, 오래 유지되는 연결을 거부하거나, wss 호스트를 명시적으로 등록해야만 허용합니다. HTTP 계층은 되고, 로그인 후 1분 안에 회색 띠가 뜹니다.
wss 호스트에 SSL 복호화가 켜져 있습니다. Slack 관리자 문서는 분명하게 말합니다. 프록시가 SSL을 복호화한다면 그 프록시가 WebSocket을 지원하거나, 아니면 wss-primary.slack.com, wss-backup.slack.com, wss-mobile.slack.com을 예외 처리해야 합니다. upgrade를 이해하지 못하는 복호화 프록시는 같은 회색 띠를 만듭니다.
허용 목록이 slack.com에서 끝납니다. slack.com만 허용하고 Slack이 https://my.slack.com/help/urls(로그인 상태에서 보임)에 공개한 전체 목록을 넣지 않은 이그레스 필터링 네트워크에서는 부분 로드 — For some reason, Slack couldn't load., 파일 누락 — 가 생기고, wss 호스트 자체가 빠져 있으면 Slack cannot connect.가 뜹니다.
엔드포인트의 무언가가 가로막고 있습니다. Slack은 백신의 웹 실드, 광고 차단 확장 프로그램, VPN 클라이언트를 간섭 요인으로 꼽고, 오래된 데스크톱 앱은 그 자체로 원인이라고 명시합니다.
어느 계층이 막혔는지 보여 주는 curl 프로브 두 개
문제가 생긴 PC에서 실행합니다. Windows 10·11에는 curl.exe가, macOS와 Linux에는 curl이 기본으로 들어 있습니다. 첫 번째는 평범한 HTTPS가 WebSocket 호스트까지 닿기는 하는지 확인합니다:
curl -sS https://wss-primary.slack.com/<html><body>Someone at Slack probably asked you to load this page to test your connection, and... it worked! Phew.</body></html>이 페이지는 정확히 이 테스트를 위해 wss 호스트에 있습니다. 프록시 차단 페이지나 타임아웃, "access denied"가 나오면 호스트가 통과되지 않는 것 — 첫 번째나 세 번째 원인입니다. 두 번째 프로브는 토큰 없이 WebSocket upgrade를 보냅니다. Slack 게이트웨이는 이를 거부하는데, 어떤 방식으로 거부하는지가 upgrade가 Slack까지 닿았는지를 알려 줍니다:
curl -si -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Sec-WebSocket-Version: 13" -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" https://wss-primary.slack.com/HTTP/1.1 400 Bad Request
content-type: text/html; charset=UTF-8
via: ingress-wss-…
server: envoy
connection: close
{"type":"error","error":{"msg":"missing token","code":1,"source":"gatewayserver-…"}}server: envoy와 missing token이 붙은 400이 좋은 결과입니다. upgrade가 손대지 않은 채 통과했고 Slack 자체 게이트웨이가 답한 것입니다. 403이나 502, HTML 페이지, 혹은 프록시 벤더 이름이 들어간 server: 헤더가 나오면 upgrade가 Slack에 닿기 전에 가로채인 것 — 첫 번째나 두 번째 원인입니다. 이 둘을 가르려면 curl이 받은 인증서를 누가 서명했는지 봅니다:
curl -sv https://wss-primary.slack.com/ -o /dev/null 2>&1 | grep -E 'subject:|issuer:'발급자가 공개 CA가 아니라 회사 CA라면 이 호스트에 복호화가 켜져 있는 것 — 두 번째 원인입니다. Windows에서는 PowerShell의 Test-NetConnection wss-primary.slack.com -Port 443이 TcpTestSucceeded : True로 포트를 확인해 주는데, 정책상 curl이 막혀 있을 때 유용합니다.
해결 1: wss 호스트 세 개를 예외 처리하고 upgrade를 통과시키기
프록시에서 wss-primary.slack.com, wss-backup.slack.com, wss-mobile.slack.com을 SSL 복호화 우회 목록에 넣고, 443 포트의 *.slack.com 정책이 WebSocket upgrade와 장시간 연결을 허용하는지 확인합니다. 설정 이름은 벤더마다 다르니 관리자 가이드에서 "WebSocket"을 찾아보세요. upgrade 프로브가 envoy의 400 missing token을 돌려줄 때까지 다시 실행한 뒤, 사용자에게 Restart Slack을 누르게 합니다.
해결 2: slack.com만이 아니라 Slack 목록 전부를 허용하기
로그인한 뒤 https://my.slack.com/help/urls를 열어 항목 전부를 이그레스 또는 프록시 허용 목록에 넣습니다. 이 목록은 Slack이 갱신하므로, 티켓에 한 번 붙여 넣고 끝내지 말고 주기적인 확인 일정을 걸어 두세요. 그런 다음 문제의 PC에서 Slack 자체 점검 — https://my.slack.com/help/test — 을 돌립니다. 브라우저에서 primary와 backup WebSocket 경로를 각각 시험하고 결과를 알려 줍니다.
해결 3: 엔드포인트, 그리고 앱 자체
백신의 웹 실드에서 Slack을 제외하고, VPN을 끊은 상태로 앱을 띄워 스플릿 터널링이 wss 호스트를 막힌 경로로 보내고 있지 않은지 보고, 브라우저에서는 확장 프로그램을 끈 시크릿 창으로 테스트합니다. 데스크톱 앱을 업데이트하세요. Slack은 오래된 버전이 연결 문제와 기능 고장까지 일으킨다고 명시합니다. 상태가 꼬인 것 같은 클라이언트는 Help → Troubleshooting → Clear Cache and Restart를 씁니다.
실제 사례: 복호화 도입, 웹은 되는데 채널은 조용
한 IT 팀이 금요일에 사무실 프록시에 SSL 복호화를 켰습니다. 월요일, Slack은 모두에게 열렸지만 메시지가 하나도 오지 않았고, 모든 데스크톱에 회색 Last updated… 띠가 떠 있었습니다. slack.com 브라우징은 됐기 때문에 처음에는 Slack 장애를 의심했지만 상태 사이트는 정상이었습니다. 자리의 PC에서 curl -sS https://wss-primary.slack.com/은 "it worked! Phew." 페이지를 돌려줘 호스트는 닿았지만, upgrade 프로브는 프록시 이름이 들어간 server: 헤더와 HTML 페이지를 실은 403으로 돌아왔고 issuer:는 회사 CA였습니다. wss 호스트 세 개를 복호화 우회에 넣자 프로브가 envoy의 400 missing token으로 바뀌었고, 엔드포인트는 손대지 않은 채 다음 재시작에서 Slack이 다시 연결됐습니다.
확인하고, 다음 프록시 변경이 되풀이하지 않게 하기
문제의 PC에서 upgrade 프로브는 server: envoy의 400을 돌려줘야 하고, https://my.slack.com/help/test는 primary와 backup을 모두 통과해야 합니다. Slack에서는 회색 띠가 사라지고, 휴대폰에서 보낸 메시지가 새로고침 없이 데스크톱에 뜹니다. 재발을 막으려면 wss 호스트 세 개와 /help/urls 목록을 프록시 변경 체크리스트에 넣어 두고, curl 프로브 두 개를 헬프데스크 런북에 적어 첫 대응이 재설치가 아니라 사실 확인이 되게 하고, 문제가 간헐적이라면 Net Logs — Help → Troubleshooting → Restart and Collect Net Logs, 재현, Stop Logging — 를 모아 Downloads의 zip을 Slack 지원팀에 보내세요.
비슷해 보이는 다른 메시지들
For some reason, Slack couldn't load.는 소켓이 아니라 웹 계층의 실패입니다. 캐시를 지우고(데스크톱: Help → Troubleshooting → Clear Cache and Restart, 브라우저: 확장 프로그램 끈 시크릿 창) 허용 목록을 확인하세요. Sorry! Something went wrong, but we're looking into it.은 Slack 쪽 문제이니 새로고침하고 상태 사이트를 봅니다. 브라우저의 평범한 No internet 페이지는 Slack보다 아래 계층의 문제입니다.
다음에 회사 네트워크에서 회색 띠를 만나면 이 순서를 거꾸로 따라가 보세요. wss 호스트로 평범한 GET, upgrade 프로브, issuer 줄 — 그리고 앱이 아니라 프록시를 고치면 됩니다.
관련 질문
채널과 히스토리는 뜨는데 새 메시지가 전혀 오지 않는 이유가 무엇인가요?
불러오기는 평범한 HTTPS이고, 전달은 Slack 관리자 안내대로 443 포트로 wss-*.slack.com 호스트에 붙는 WebSocket입니다. 요청-응답 HTTP는 처리하면서 WebSocket으로의 Upgrade를 떼어 내거나 거부하는 프록시가 있으면 정확히 그렇게 갈립니다. 페이지는 되고 회색 "Last updated…" 띠가 뜹니다. 본문의 upgrade 프로브가 upgrade가 Slack 게이트웨이까지 닿는지 보여 줍니다.
443 포트면 충분한가요, 아니면 다른 포트도 열어야 하나요?
메시징에 대해 Slack 관리자 문서는 wss 호스트 세 개로 가는 443 포트의 지속 WebSocket 연결과, 앱의 나머지 부분을 위한 my.slack.com/help/urls 도메인 목록을 설명합니다. 포트를 더 여는 대신 도메인을 추가하세요. 이 목록은 Slack이 관리하므로 프록시가 바뀔 때마다 확인하시기 바랍니다.
정책상 복호화 예외를 둘 수 없습니다. 어떤 선택지가 있나요?
Slack의 표현은 프록시가 WebSocket을 지원하거나, 아니면 wss-primary·wss-backup·wss-mobile.slack.com을 예외 처리해야 한다는 것입니다. 프록시 벤더가 복호화를 거치는 WebSocket upgrade를 지원한다면 *.slack.com에 대해 그것을 켜고, upgrade 프로브가 envoy의 400 "missing token"을 돌려줄 때까지 다시 실행하세요. 지원하지 않는다면 Slack이 문서화한 길은 예외 처리뿐입니다.
Net Logs에는 무엇이 담기고 어디로 보내나요?
Help → Troubleshooting → Restart and Collect Net Logs는 네트워크 로깅을 켠 채 앱을 재시작합니다. 문제를 재현하고 Stop Logging을 누르면 Downloads에 zip이 생깁니다. Slack은 지원팀에 문의할 때 이 파일을 첨부해 달라고 합니다. 앱이 보낸 요청이 기록돼 있으니 공개된 곳에 올리지 마세요.
모바일 앱에는 다른 규칙이 필요한가요?
Slack은 복호화에서 예외 처리할 WebSocket 호스트 셋 중 하나로 wss-mobile.slack.com을 명시하므로, 예외나 허용 목록 항목에 wss-primary·wss-backup과 함께 이 호스트도 넣어야 하고, my.slack.com/help/urls의 도메인 목록은 사무실 Wi-Fi에 붙은 휴대폰에도 똑같이 적용됩니다.
참고 자료
- Slack Help Center — Manage Slack connection issues (WebSockets over port 443, my.slack.com/help/urls allowlist, exempt wss-primary/backup/mobile.slack.com from SSL decryption, my.slack.com/help/test, Net Logs)
- Slack Help Center — Troubleshoot connection issues ("Slack cannot connect", the "Last updated…" WebSocket banner, Restart and Collect Net Logs, Clear Cache and Restart)
Haneul Seo
Infrastructure engineer · 10+ years running Linux fleets
같은 카테고리 다른 글
Gmail이 550-5.7.26으로 거부: 도메인의 DMARC 정책 때문에 인증되지 않은 메일이 수신 거부됨
Gmail이 우리 도메인이 직접 게시한 DMARC 정책을 집행한 결과입니다. 메시지가 header From: 도메인 기준으로 SPF·DKIM 정렬을 모두 통과하지 못했고, p=quarantine이나 p=reject 정책이 이를 하드 바운스로 바꿉니다. Authentication-Results 헤더가 어느 검사가 실패했는지 알려주고, SPF·DMARC·DKIM 레코드를 향한 dig 세 번이 원인을 지목합니다. SPF나 DKIM으로 인증하라는 비슷한 문구의 바운스는 정책이 아니라 Gmail의 기본 발신자 요구사항에 걸린 다른 문제입니다.
Microsoft Entra ID: AADSTS50011, 요청에 지정된 redirect URI 가 앱에 등록된 redirect URI 와 일치하지 않음
로그인은 끝까지 성공했는데 마지막 한 단계에서 Entra ID 가 거부합니다. 앱이 보낸 redirect_uri 가 등록된 URI 중 어느 것과도 문자 단위로 같지 않기 때문입니다. 비교는 대소문자를 구분하고 끝의 슬래시를 세며, localhost 를 제외하면 https 를 요구하고 포트도 일치해야 합니다. 목록도 web·spa·publicClient 세 개로 나뉘어 있고, application 객체가 아닌 service principal 에 넣은 URI 는 동기화 과정에서 사라질 수 있습니다. 오류 메시지에서 URI 와 앱 ID 를 꺼내 az ad app show 로 대조하고, az ad app update 나 Graph PATCH 로 정확한 문자열을 넣은 뒤 3~5분 기다리면 됩니다.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
smtp.office365.com 으로 메일을 보내던 스캐너·스크립트·앱이 535 5.7.139 로 멈추는 이유는 SMTP AUTH 프로토콜이 테넌트 전체, 해당 메일박스, 또는 Basic 인증을 막는 인증 정책·보안 기본값 중 어딘가에서 꺼져 있기 때문입니다. 문구(Tenant, Mailbox, 'did not meet the criteria')를 읽고 Get-TransportConfig·Get-CASMailbox·Get-AuthenticationPolicy 로 확인한 뒤, 테넌트 전체가 아니라 필요한 메일박스 하나만 엽니다. Basic SMTP AUTH 는 다리일 뿐입니다. Microsoft 는 2026년 12월 말 기존 테넌트에서 기본 비활성화하므로 발신자를 OAuth·High Volume Email·릴레이 커넥터로 옮겨야 합니다.
Zoom: "Unable to connect" 오류 코드 5003 — 브라우저는 되는데 데스크톱 앱만 Zoom 에 못 붙을 때
오류 5003 은 같은 PC 의 웹 클라이언트는 정상 입장하는데 Zoom 데스크톱 앱이 Zoom 서버와의 연결을 끝내지 못하는 상태입니다. 앱은 브라우저보다 더 많은 것을 필요로 합니다. Zoom 방화벽 문서는 미팅용 TCP 443/8801/8802 와 UDP 3478/3479/8801–8810, 인증서 검증용 CA 호스트 목록을 들고, zoom.us 와 *.zoom.us 를 프록시·SSL 검사에서 제외하라고 권고합니다. 포트 테스트, curl issuer 확인, 앱 내장 Network Connectivity Tool(Ctrl+Alt+Shift+D / Cmd+Option+Shift+D)로 어느 계층이 끊겼는지 보고 그 계층을 고치며, 재설치는 옆자리는 되는데 한 대만 실패할 때 씁니다.
Word: 문서가 "locked for editing by another user"라며 열리지 않음
Word가 문서의 잠금(owner file)을 발견해 다른 누군가가 열어 두었다고 판단하고 읽기 전용 사본만 제안합니다. 대개는 아무도 열지 않았습니다: 크래시가 잠금을 남겼거나, 숨은 Word 프로세스가 여전히 파일을 쥐고 있는 것입니다. 어느 쪽인지 확인하고 Word 인스턴스를 모두 닫은 뒤 남겨진 ~$ owner file을 삭제하면 문서가 다시 편집 가능하게 열립니다.
OneDrive: 동기화 멈춤 — 일시 중지 또는 아이콘의 빨간 X
OneDrive 아이콘의 빨간 원 안 흰색 X나 일시 중지 상태는 동기화 루프가 멈췄다는 뜻입니다 — 파일은 로컬과 클라우드에 안전하지만 둘 사이를 오가지 않습니다. 활동 목록을 읽어 클라이언트 문제인지 특정 파일 문제인지 가른 뒤 OneDrive를 재시작하고, 그래도 안 되면 리셋하세요. 리셋은 동기화 연결을 다시 세울 뿐 파일을 삭제하지 않습니다.