I'm trying to use Slack but I cannot get it to work in Chrome or Firefox. I get a connection error. I use their help test and I get failures on the websockets.

I don't have the same issues when using IE.

I'm behind a work network and both browsers are using the same LAN settings. When I go into LAN settings, the only thing ticked is Use automatic configuration script and there's a url in there.

Why are the web sockets not an issue in IE and how would I stop them being an issue in other browsers?

Info: Here's some information on browser versions. Chrome: 52.02743.116 IE: 11.0.9600

When going to http://www.websocketstest.com I get the following:

IE: Websockets supported - Yes
HTTP Proxy - Yes
Port 80 - Disconnected
Port 443 - Connected
Port 8080 - Disconnected
Port 443 SSL - Connected

Chrome: Websockets supported - Yes
HTTP Proxy - Yes
All ports disconnected

Tried to connect to slack via http and wss as recommended in the comments but it just reverts to https.


  • well, modern versions of Chrome and FF both support websockets: en.wikipedia.org/wiki/WebSocket#Browser_implementation Aug 18 '16 at 18:27
  • Yep, i'm not doubting that they're supported, it's that they seem to be blocked or not working. Aug 18 '16 at 18:30
  • IE didn't support websockets until late versions of IE10. it could be that slack falls back to a different mechanism on this version that is compatible with your work environment network. Perhaps provide your browser versions you've tried in the question. Some proxy servers are transparent and work fine with WebSocket; others will prevent WebSocket from working correctly, causing the connection to fail. In the off chance you're visiting slack over http://, I'd suggest trying https and wss://, you may trigger different rules, and websocket traffic may flow.
    – init_js
    Sep 6 '16 at 6:21

I suspect a mismatch in the proxy settings of the different browsers.

If IE's proxy settings were configured manually, these settings will have to be repeated in your other browsers. If they are configured automatically, hopefully all browsers should be receiving the same settings -- any discrepancy there may cause these failures.

The proxy auto-configuration script (PAC) in your environment could use some features only working well in IE. Is a PAC script downloaded to your browser (result of "Detecting Proxy Settings...") or visible in your browser's proxy settings ?

In recent versions of chrome, you can view the current PROXY settings by visiting URL: chrome://net-internals/#proxy . These settings hopefully match those of IE . Proxy settings in Firefox can be viewed or changed by following the instructions in https://support.mozilla.org/en-US/kb/advanced-panel-settings-in-firefox (look for "Automatic proxy configuration URL" in that page). If you know with certainty that your work environment's proxy settings are "configured automatically", set all your browsers as such.

If you come to the a point where all browsers proxy settings are the same and a PAC file is involved. I.e. it is possible the file obtained with wpad may work in one browser, but not in another, you'll have to investigate deeper.

  1. The first pointer in the list below can help one download the proxy script file in IE. If the PAC file URL is served by a webserver (i.e. the wpad file is a http(s):// url), I would recommend first checking if downloaded versions of the same file from IE, Chrome, and Firefox are all exactly the same. This webserver might change its response based on the requesting user-agent. One has to inspect the version for the browser that's not working if they are different.

  2. Once the script that Chrome or Firefox would use is obtained, one must inspect it. That's the harder part. One has to simulate what the script would do if it were to be supplied slack.com's websocket URL and host. Maybe this can be done by visual inspection and deduction, but if the script is very complicated, a tool may be used (see the debugging link in the list).

  3. One thing to watch out for are the presence of functions not supported by the particular browser. I suspect errors encountered in those scripts are not well reported to the user, and behaviour in error cases might be ill-defined.

At this point I can only provide pointers.

and some background info:

  • Ok, yes i'm using a proxy settings from a wpad.dat just like your linked example. I can open that in notepad but don't fully understand what's going on. Is there something in particular I should look for? Sep 7 '16 at 8:16
  • Browsers consult the pac file for every web request and run its FindProxyForURL(url, host) function with the url and hostname of the request. The role of that function is to return "DIRECT" to access the url directly, or return locations of one or more proxy servers ("[PROXY ip:port;]+"). Determine the prescribed action when slack.com's websocket url were to pass in. Also, try downloading the wpad script from different browsers, the webserver serving it might respond with a different version based on user-agent. Would your workplace allow you posting the script here if it's not too long?
    – init_js
    Sep 7 '16 at 19:29
  • added information on manual proxy configuration too. I figured maybe IE was configured manually (e.g. at system installation time), and settings may just need to be repeated in other browsers.
    – init_js
    Sep 7 '16 at 20:06
  • Firefox, Chrome, and IE all use the OS's proxy settings by default. I would agree something with the proxy configuration is causing this problem with Slack.
    – Ramhound
    Sep 7 '16 at 20:16
  • @Ramhound yeo I can confirm that all browsers are using the system wide proxy settings Sep 7 '16 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.