Windscribe causes connection header to be removed on insecure HTTP requests on port 80

[eqiy]

Describe the bug
When Windscribe is turned on, the Connection HTTP header is missing for insecure HTTP requests on port 80. This causes WebSocket upgrades to fail.

OS and app information:

• OS: Windows 10 21H42
• App version: 2.13.8

To Reproduce
Server (must not be localhost):

sudo ncat -k -l 80

Client:

curl -v -i \
    -H "Connection: Upgrade" \
    -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
    -H "Sec-WebSocket-Version: 13" \
    http://<SERVER_IP>

Expected behavior
The server outputs this when Windscribe is not running:

GET / HTTP/1.1
Host: <SERVER_IP>
User-Agent: curl/8.9.1
Accept: */*
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

Actual behavior
The server outputs this when Windscribe is running:

GET / HTTP/1.1
Host: <SERVER_IP>
User-Agent: curl/8.9.1
Accept: */*
Sec-Websocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-Websocket-Version: 13
Upgrade: websocket

As shown above, the Connection header is not sent when Windscribe is running.

Additional context
This issue doesn't happen on other ports, it doesn't happen on HTTPS, and it doesn't happen when the server is hosted locally. It appears to only occur for HTTP on port 80 when connecting to an external IP.

[jaxu]

I'm fairly certain we don't actually modify any HTTP traffic that flows through, so this is most likely just a websocket handshake failure. Nonetheless, just so I have a clear understanding:

• You say this happens as long as Windscribe is running, not necessarily connected to any VPN, right?
• Does it matter if the 'server' is on the LAN or does it have to be really external?

[eqiy]

@jaxu To clarify, the issue occurs when Windscribe is running and connected to a VPN. It works when having Windscribe running, but not connected. I can never reproduce it on LAN server.

I'm fairly certain we don't actually modify any HTTP traffic that flows through

This is what I expected as well, but I tested on multiple machines and different Windscribe servers, and when the request goes through Windscribe, that Connection header disappears.

this is most likely just a websocket handshake failure

This is the reason why I have the server running ncat instead of any WebSocket server. That Connection header is simply gone when the HTTP request goes through Windscribe. For further context, the external server is Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-1013-oracle x86_64) on an Oracle Cloud VPS without any firewall or reverse proxy AFAIK. It works on any port other than 80, so I am unsure what the culprit.

[jaxu]

Thanks for the additional info, that helps. We'll investigate.

[jaxu]

I've been unable to replicate this.

I used the same setup as you: ncat -k -l 80 on an Arch machine directly connected to the internet, and my laptop running off a Wi-Fi hotspot from my phone, running the same curl command as you.

I tried while connected via a variety of protocols and locations and it always gave the same, expected headers.

In fact, I can just point this to a public http echo server:

curl -v -i \
    -H "Connection: Upgrade" \
    -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
    -H "Sec-WebSocket-Version: 13" \
    http://echo.free.beeceptor.com

and it too indicates that it has received all the headers. Can you please try against this as well to eliminate the possibility that it's an issue with the server?

If you still see the same behavior, please send in a debug log and provide me your username so I can take attempt to reproduce this with your environment.

[eqiy]

@jaxu I have just tried it with that public HTTP echo server (server is New York Grand Central) and the issue still happens:

curl -v \
    -H "Connection: Upgrade" \
    -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
    -H "Sec-WebSocket-Version: 13" \
    http://echo.free.beeceptor.com

*   Trying 147.182.252.2:80...
* Connected to echo.free.beeceptor.com (147.182.252.2) port 80 (#0)
> GET / HTTP/1.1
> Host: echo.free.beeceptor.com
> User-Agent: curl/7.81.0
> Accept: */*
> Connection: Upgrade
> Upgrade: websocket
> Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
> Sec-WebSocket-Version: 13
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Content-Type: application/json
< Date: Thu, 06 Mar 2025 00:08:54 GMT
< Vary: Accept-Encoding
< Content-Length: 384
<
{
  "method": "GET",
  "protocol": "http",
  "host": "echo.free.beeceptor.com",
  "path": "/",
  "ip": "149.88.21.137:26755",
  "headers": {
    "Host": "echo.free.beeceptor.com",
    "User-Agent": "curl/7.81.0",
    "Accept": "*/*",
    "Sec-Websocket-Key": "dGhlIHNhbXBsZSBub25jZQ==",
    "Sec-Websocket-Version": "13",
    "Accept-Encoding": "gzip"
  },
  "parsedQueryParams": {}
* Connection #0 to host echo.free.beeceptor.com left intact

[eqiy]

As expected, when the VPN is off, it works:

curl -v \
    -H "Connection: Upgrade" \
    -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
    -H "Sec-WebSocket-Version: 13" \
    http://echo.free.beeceptor.com

*   Trying 147.182.252.2:80...
* Connected to echo.free.beeceptor.com (147.182.252.2) port 80 (#0)
> GET / HTTP/1.1
> Host: echo.free.beeceptor.com
> User-Agent: curl/7.81.0
> Accept: */*
> Connection: Upgrade
> Upgrade: websocket
> Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
> Sec-WebSocket-Version: 13
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Access-Control-Allow-Origin: *
< Content-Type: application/json
< Date: Thu, 06 Mar 2025 00:37:14 GMT
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
<
{
  "method": "GET",
  "protocol": "http",
  "host": "echo.free.beeceptor.com",
  "path": "/",
  "ip": "<REAL_IP>",
  "headers": {
    "Host": "echo.free.beeceptor.com",
    "User-Agent": "curl/7.81.0",
    "Accept": "*/*",
    "Connection": "Upgrade",
    "Sec-Websocket-Key": "dGhlIHNhbXBsZSBub25jZQ==",
    "Sec-Websocket-Version": "13",
    "Upgrade": "websocket",
    "Accept-Encoding": "gzip"
  },
  "parsedQueryParams": {}
* Connection #0 to host echo.free.beeceptor.com left intact
}

[jaxu]

Ah, this might be caused by the "Unlock Streaming" feature on the server-side. Please log into your Windscribe account from the website and disable the toggle and see if that resolves it for you.

[eqiy]

@jaxu I just tested and it works now with unlock streaming off once I reconnected to the VPN.