Slack: "Slack cannot connect" and the grey "Last updated…" banner behind a corporate proxy
Hi, it's BlueByte. Slack opens, the channel list loads, and then a grey bar says Last updated less than a minute ago… — new messages stop arriving — or the app gives up with Slack cannot connect. and a Restart Slack button. The browser on the same machine reaches slack.com without complaint. On a company network the pattern is almost always the same: Slack's HTTP side is open and its WebSocket side is not. We'll walk through why Slack needs that second kind of connection, the four things on a corporate network that break it, the two curl probes that show which one, the fix for each, and how to keep the next proxy change from taking Slack down again.
Why Slack needs a WebSocket, not just HTTPS
Loading channels, history and files is ordinary HTTPS to *.slack.com and the asset domains Slack lists for admins. Real-time delivery — new messages, typing indicators, presence — rides on a persistent WebSocket, which Slack's admin guidance says runs over port 443 to three hosts it names: wss-primary.slack.com, wss-backup.slack.com and wss-mobile.slack.com — the names are our reading of primary, fallback and mobile; Slack lists them without roles. A WebSocket begins as an HTTPS request carrying Upgrade: websocket; the server answers 101 Switching Protocols and the connection stays open for hours. Anything in between that only understands request-and-response HTTP, or that terminates TLS and re-encrypts without understanding the upgrade, leaves Slack with a working web layer and a dead message stream. That is what the grey banner reports; Slack's own wording is that you won't automatically receive new messages from your channels or DMs.
The four ways a company network breaks it
The proxy or firewall does not pass WebSockets. Some web proxies strip the Upgrade header, refuse long-lived connections, or only allow the wss hosts if they are named explicitly. The HTTP layer works and the banner appears within a minute of sign-in.
SSL decryption is on for the wss hosts. Slack's admin article is explicit: if your proxy decrypts SSL, it must either support WebSockets or you need to exempt wss-primary.slack.com, wss-backup.slack.com and wss-mobile.slack.com. A decrypting proxy that does not understand the upgrade produces the same banner.
The allowlist stops at slack.com. Egress-filtered networks that allow slack.com but not the full list Slack publishes at https://my.slack.com/help/urls (visible when signed in) get partial loads — For some reason, Slack couldn't load., missing files — or Slack cannot connect. when the wss hosts themselves are missing.
Something on the endpoint is in the way. Slack names antivirus web shields, ad-blocking extensions and VPN clients as interference, and an outdated desktop app as a cause on its own.
Two curl probes that show which layer is blocked
Run these from the affected machine; Windows 10 and 11 ship curl.exe, macOS and Linux ship curl. The first checks that plain HTTPS reaches the WebSocket host at all:
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>That page exists on the wss host for exactly this test. A proxy block page, a timeout or an "access denied" means the host is not allowed through — cause one or three. The second probe sends a WebSocket upgrade with no token. Slack's gateway rejects it, and the way it rejects it tells you whether the upgrade reached 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-…"}}A 400 with server: envoy and missing token is the good outcome: the upgrade passed through untouched and Slack's own gateway answered. A 403, a 502, an HTML page, or a server: header naming your proxy vendor means the upgrade was intercepted before Slack — cause one or two. To split those two, look at who signed the certificate curl received:
curl -sv https://wss-primary.slack.com/ -o /dev/null 2>&1 | grep -E 'subject:|issuer:'An issuer that is your company's CA rather than a public CA means decryption is on for this host — cause two. On Windows, Test-NetConnection wss-primary.slack.com -Port 443 in PowerShell confirms the port with TcpTestSucceeded : True, which is useful when curl is blocked by policy.
Fix 1: exempt the three wss hosts and let the upgrade through
On the proxy, add wss-primary.slack.com, wss-backup.slack.com and wss-mobile.slack.com to the SSL-decryption bypass, and confirm the policy for *.slack.com on 443 permits WebSocket upgrades and long-lived connections — the setting's name varies by vendor, so search the admin guide for "WebSocket". Re-run the upgrade probe until it returns envoy's 400 missing token, then have a user click Restart Slack.
Fix 2: allowlist everything on Slack's list, not just slack.com
Sign in, open https://my.slack.com/help/urls, and add every entry to the egress or proxy allowlist. Slack maintains that list, so put a recurring reminder against it rather than pasting it into a ticket once. Then run Slack's own check from the affected machine — https://my.slack.com/help/test — which exercises the primary and backup WebSocket paths from the browser and reports each.
Fix 3: the endpoint, and the app itself
Exclude Slack from antivirus web shields; try the app with the VPN disconnected to see whether split tunnelling is routing the wss hosts somewhere they are blocked; in the browser, test in a private window with extensions off. Update the desktop app — Slack states that older versions cause connection issues and even broken features. For a client that seems stuck in a bad state, use Help → Troubleshooting → Clear Cache and Restart.
A real case: decryption rollout, working web, silent channels
An IT team turned on SSL decryption at the office proxy on a Friday. Monday, Slack loaded for everyone and no messages arrived; the grey Last updated… banner sat on every desktop. Browsing to slack.com worked, so the first suspicion was a Slack outage — the status site said no. From a desk machine, curl -sS https://wss-primary.slack.com/ returned the "it worked! Phew." page, so the host was reachable, but the upgrade probe came back 403 with an HTML page and a server: header naming the proxy, and issuer: showed the company CA. They added the three wss hosts to the decryption bypass, the probe flipped to envoy's 400 missing token, and Slack reconnected on the next restart with no change on the endpoints.
Verify, and stop the next proxy change from repeating it
From the affected machine, the upgrade probe should return 400 from server: envoy, and https://my.slack.com/help/test should pass primary and backup. In Slack, the grey banner clears and a message sent from a phone shows up on the desktop without a reload. To prevent recurrence: keep the three wss hosts and the /help/urls list in the proxy change checklist; put the two curl probes in the help desk runbook so the first response is a fact rather than a reinstall; and if the problem is intermittent, collect Net Logs — Help → Troubleshooting → Restart and Collect Net Logs, reproduce, Stop Logging — and send the zip from Downloads to Slack support.
Adjacent messages that look the same
For some reason, Slack couldn't load. is the web layer failing, not the socket: clear the cache (desktop: Help → Troubleshooting → Clear Cache and Restart; browser: private window, extensions off) and check the allowlist. Sorry! Something went wrong, but we're looking into it. is on Slack's side — reload and check the status site. A plain browser No internet page is below Slack entirely.
Next time you see the grey banner on a company network, walk these checks back in order: plain GET to the wss host, the upgrade probe, the issuer line — and fix the proxy, not the app.
Related questions
Why do channels and history load but new messages never appear?
Loading is plain HTTPS; delivery is a WebSocket that Slack's admin guidance runs over port 443 to the wss-*.slack.com hosts. A proxy that handles request-and-response HTTP but strips or refuses the Upgrade to WebSocket gives you exactly that split — a working page and the grey "Last updated…" banner. The upgrade probe in the article shows whether the upgrade reaches Slack's gateway.
Is port 443 enough, or does Slack need other ports open?
For messaging, Slack's admin article describes persistent WebSocket connections over port 443 to the three wss hosts, plus the domain list at my.slack.com/help/urls for the rest of the app. Add the domains rather than opening more ports; Slack maintains that list, so check it when the proxy changes.
Our policy does not allow decryption exemptions. What are the options?
Slack's wording is that the proxy must either support WebSockets or exempt wss-primary, wss-backup and wss-mobile.slack.com. If your proxy vendor supports WebSocket upgrades through decryption, enable that for *.slack.com and re-run the upgrade probe until it returns envoy's 400 "missing token". If it does not, the exemption is the only path Slack documents.
What do Net Logs contain and where do they go?
Help → Troubleshooting → Restart and Collect Net Logs restarts the app with network logging on; reproduce the problem, click Stop Logging, and a zip appears in Downloads. Slack asks you to attach it when you contact support. Do not post it publicly — it records the requests the app made.
Does the mobile app need a different rule?
Slack lists wss-mobile.slack.com among the three WebSocket hosts to exempt from decryption, so any exemption or allowlist entry must include it alongside wss-primary and wss-backup, and the domain list at my.slack.com/help/urls applies to phones on the office Wi-Fi too.
References
- 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
More in this category
Gmail rejects your mail with 550-5.7.26: unauthenticated email is not accepted due to the domain's DMARC policy
Gmail enforced the DMARC policy your own domain publishes: the message failed both SPF and DKIM alignment against the header From: domain, so a p=quarantine or p=reject policy turned it into a hard bounce. The Authentication-Results header names the failing check, and three dig queries against your SPF, DMARC and DKIM records name the cause. A near-identical bounce about authenticating with SPF or DKIM is a different problem — Gmail's baseline sender requirements, not your policy.
Microsoft Entra ID: AADSTS50011, the redirect URI specified in the request does not match the redirect URIs configured for the application
Sign-in completes and then Entra ID refuses the last hop, because the redirect_uri your app sent is not a byte-for-byte match for any URI registered on the app. The match is case-sensitive, counts the trailing slash, requires https outside localhost, and treats the port as significant everywhere except localhost. It also splits by platform: web, spa and publicClient are three separate lists, and URIs added to the service principal instead of the application object can disappear. Read the URI and the app ID out of the error, compare them with az ad app show, add the exact string with az ad app update or a Graph PATCH, then wait three to five minutes.
Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled
A scanner, script or app that sends through smtp.office365.com gets 535 5.7.139 because the SMTP AUTH protocol is switched off for the tenant, for that mailbox, or by an authentication policy or security defaults that block Basic authentication. Read the wording (Tenant, Mailbox, or 'did not meet the criteria'), confirm with Get-TransportConfig, Get-CASMailbox and Get-AuthenticationPolicy, then open SMTP AUTH on the one mailbox that needs it rather than tenant-wide. Treat Basic SMTP AUTH as a bridge: Microsoft disables it by default for existing tenants at the end of December 2026, so move the sender to OAuth, High Volume Email or a relay connector.
Zoom: "Unable to connect" error code 5003 — the desktop app can't reach Zoom while the browser can
Error 5003 is the Zoom desktop app failing to complete its connection to Zoom's servers while the web client on the same machine joins fine. The app needs more than a browser does: Zoom's firewall article lists TCP 443/8801/8802 and UDP 3478/3479/8801–8810 for meetings, a set of CA hosts for certificate validation, and it asks that zoom.us and *.zoom.us be exempted from proxy or SSL inspection. A port test, a curl issuer check, and the app's built-in Network Connectivity Tool (Ctrl+Alt+Shift+D / Cmd+Option+Shift+D) show which of those is cut; fix that layer, and reinstall only when a single machine fails while its neighbours join.
Word: "The document is locked for editing by another user"
Word found a lock — an owner file — for the document and assumed someone else has it open, so it offers only a read-only copy. Usually no one does: a crash left the lock behind, or a hidden Word process is still holding the file. Confirm which, close every Word instance, delete the stale ~$ owner file, and the document opens for editing again.
OneDrive: sync stuck — paused or a red X on the icon
A red circle with a white cross, or a paused status, on the OneDrive icon means the sync loop has stopped — your files are safe locally and in the cloud, but they aren't moving between them. Read the activity list to see whether it's the client or one bad file, then restart OneDrive, and reset it if a restart isn't enough. Resetting rebuilds the sync links and doesn't delete files.