Threading version server doesn't allow external connections (works fine with localhost)

[cfinnberg]

I'm just trying some basic examples of websockets.

I'm using two different computers for client and server, so I have just adjusted the server host to be "" (all interfaces). First I tried a threading version:

from websockets.sync.server import serve

def hello(websocket):
    name = websocket.recv()
    print(f"< {name}")

    greeting = f"Hello {name}!"

    websocket.send(greeting)
    print(f"> {greeting}")

with serve(hello, "", 8765) as server:
    server.serve_forever()

I can see the program listening at 8765 in the output of ss --tcp --listening --numeric:

LISTEN                0                      128                                          0.0.0.0:8765                                      0.0.0.0:* 

I can connect fine from the same server using the server ip/name or localhost:

websockets ws://myserver:8765

But if I try to connect from other computer (different network), with the same command, it can't connect and gives a timeout error:

Failed to connect to ws://myserver:8765: timed out during opening handshake.

I have tried to solve this, but I can't see where the problem is. Tried also with another server computer with the same results.

The asyncio version works flawlessly and I am able to connect to it from both localhost and remote computer, so I suspect some kind of bug here.

Can someone reproduce the problem? Am I missing something (probably really simple) here? thanks.

Server and client are Linux.
Python version is 3.13.11
There is no firewall running/installed in neither computer.
Websockets version is 15.0.1

[aaugustin]

Could you enable debug logs on the server and paste the output?

Based on the error message, the client manages to connect and likely sends the opening handshake request, but never gets the opening handshake response.

It would be interesting to see whether the server receives the handshake request and where it blocks.

[cfinnberg]

Hi, thanks for your reply. I am able to enable logs, but for external connections it doesn't show anything.

I don't know why I hadn't thought of it before (I was probably tired), but I tested a simple python http server at the same port with the same results. So I have come to the conclusion that it has to be my systems somehow. I still don't know where it is, but I have to have a firewall enabled somewhere somehow. So closing this for now and sorry for the noise...

[aaugustin]

No worries.

FYI websockets relies on socket.create_server under the hood. If the following works:

import socket
server_sock = socket.create_server(("", 8765))
conn_sock, addr = server_sock.accept()

then websockets should work.

[cfinnberg]

Ok, just for closure... :)

After wasting some time looking for the hiding firewall in my Linux systems (I had started to reconsider my Linux knowledge...), I realized that if it is not inside, it should be outside. And outside my servers is the hosting provider. And then I remembered that some time ago I wanted to test the firewall my hosting provider offers for free... and after that I forgot about it. Yep, I must shamefully admit that it was another case of PEBCAK.

Why it worked with the asyncio version and not with the threading version? Well, I now have noticed that with asyncio the empty string in host parameter defaults to both IPv4 and IPv6, and the threading version defaults to just IPv4. My test firewall was apparently active just for IPv4.

At least everything has an explanation... :)

[aaugustin]

with asyncio the empty string in host parameter defaults to both IPv4 and IPv6, and the threading version defaults to just IPv4

Indeed create_server in the socket module defaults to family=AF_INET (likely for backwards compatibility) while create_server in the asyncio module defaults to family=AF_UNSPEC, leading to this difference in behavior.

I have decided against attempting to patch internal inconsistencies in the stdlib and to document that websockets behaves like the stdlib. Unfortunately, this means that websockets misbehaves when the stdlib misbehaves!