Hi,
I'm experiencing an issue with the AISStream WebSocket service.
The client successfully connects to the WebSocket endpoint and sends the subscription message, but it never receives any AIS messages. The connection remains open indefinitely without any errors or data.
Environment:
Operating System: Windows Server
Python: 3.13
websockets: latest version
FastAPI + Uvicorn (although the same behavior occurs in a standalone Python script)
Endpoint:
wss://stream.aisstream.io/v0/stream
Subscription
{
"APIKey": "<valid_api_key>",
"BoundingBoxes": [[[-90, -180], [90, 180]]],
"FilterMessageTypes": ["PositionReport"]
}
I also tested without FilterMessageTypes and with specific MMSI filters. The behavior is exactly the same.
Observed behavior:
WebSocket connection is established successfully.
Subscription message is sent successfully.
The connection remains open.
No exceptions are raised.
No messages are ever received.
The server does not close the connection.
Application log:
AISstream: bbox=[[[-90.0, -180.0], [90.0, 180.0]]] | types=['PositionReport'] | mmsis=all vessels
SUBSCRIBE: {"APIKey":"","BoundingBoxes":[[[-90.0,-180.0],[90.0,180.0]]],"FilterMessageTypes":["PositionReport"]}
Connected to AISstream
At this point the client waits indefinitely. The async for raw in websocket: loop is never entered because no frames are received.
Additional tests:
Tested from multiple Windows machines.
Internet connectivity is working.
TCP connection to stream.aisstream.io:443 succeeds.
WebSocket handshake succeeds.
The same behavior occurs using both:
a minimal Python example from the documentation;
a production application.
Expected behavior
After sending the subscription message, the server should start streaming AIS messages matching the subscription.
Question:
Has there been any recent change to the WebSocket API, authentication, or subscription protocol that could explain this behavior?
Is there any known service issue, account restriction, or additional requirement that would cause the connection to remain open while delivering no messages?
Thank you.
Hi,
I'm experiencing an issue with the AISStream WebSocket service.
The client successfully connects to the WebSocket endpoint and sends the subscription message, but it never receives any AIS messages. The connection remains open indefinitely without any errors or data.
Environment:
Operating System: Windows Server
Python: 3.13
websockets: latest version
FastAPI + Uvicorn (although the same behavior occurs in a standalone Python script)
Endpoint:
wss://stream.aisstream.io/v0/stream
Subscription
{
"APIKey": "<valid_api_key>",
"BoundingBoxes": [[[-90, -180], [90, 180]]],
"FilterMessageTypes": ["PositionReport"]
}
I also tested without FilterMessageTypes and with specific MMSI filters. The behavior is exactly the same.
Observed behavior:
WebSocket connection is established successfully.
Subscription message is sent successfully.
The connection remains open.
No exceptions are raised.
No messages are ever received.
The server does not close the connection.
Application log:
AISstream: bbox=[[[-90.0, -180.0], [90.0, 180.0]]] | types=['PositionReport'] | mmsis=all vessels
SUBSCRIBE: {"APIKey":"","BoundingBoxes":[[[-90.0,-180.0],[90.0,180.0]]],"FilterMessageTypes":["PositionReport"]}
Connected to AISstream
At this point the client waits indefinitely. The async for raw in websocket: loop is never entered because no frames are received.
Additional tests:
Tested from multiple Windows machines.
Internet connectivity is working.
TCP connection to stream.aisstream.io:443 succeeds.
WebSocket handshake succeeds.
The same behavior occurs using both:
a minimal Python example from the documentation;
a production application.
Expected behavior
After sending the subscription message, the server should start streaming AIS messages matching the subscription.
Question:
Has there been any recent change to the WebSocket API, authentication, or subscription protocol that could explain this behavior?
Is there any known service issue, account restriction, or additional requirement that would cause the connection to remain open while delivering no messages?
Thank you.