We’re trying to configure a third-party ASP.NET Core application that uses WebSockets on a windows server machine (IIS). When the application runs over HTTP, the WebSocket calls work as expected and the channel is successfully established between the client and the server.

However, when the application is run over HTTPS, the wss:// request used to establish the WebSocket connection fails with a 404 error.

According to appsettings.json, the application is configured to run out of process. We’ve observed that when the client establishes the socket over a non-TLS connection (HTTP), the response’s Server HTTP header identifies IIS as the server. In contrast, when the application is accessed over TLS (HTTPS), it appears that IIS does not handle the request and instead passes it directly to Kestrel (the server is identified as Kestrel).

Below is an example of the request and response for the failing HTTPS scenario:

GET /SBC/RTDM/Control HTTP/1.1
Host: XXX
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:147.0) Gecko/20100101 Firefox/147.0
Accept: */*
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br, zstd
Sec-WebSocket-Version: 13
Origin: XXXX
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: rGGKiAJLt2Rjewh/uR7wPA==
Sec-GPC: 1
Connection: Upgrade
Cookie: ....
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: websocket
Sec-Fetch-Site: same-origin
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket 

And here's the response:

HTTP/1.1 404 Not Found
Cache-Control: no-cache, no-store
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Kestrel
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Powered-By: ASP.NET
Date: Fri, 23 Jan 2026 16:35:46 GMT