Chrome Websockets CORS policy

There is no browser enforced CORS with WebSocket. Here are 2 things that can go wrong (assuming you use both HTTPS and WSS):

• the server enforces an Origin. The Origin HTTP header is set by the browser to the origin of the HTML page containing the JavaScript that is opening the WebSocket connection. A server MAY check that header and deny. But since you say other browsers are working (which?), this is unlikely
• since you are using wss, the server certificate MUST be completely valid, and acceptable to the browser without any user interaction. Is this the case?

I came across this issue again. I still haven't figured out why, but making an OPTIONS (or any other) request to the subdomain first allows the connection to be opened.

This only seems to be a problem with wss connections, and has popped up across multiple domains and certificates.

This sounds like it has to do with making cross-origin requests that are not "simple". HTTP requests that are not simple are "preflighted" by the browser (Chrome at least) with "OPTIONS" automatically. I'm guessing the browser is just enforcing this behavior.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requestshttps://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Preflighted_requests