Causes of Client Connection Failures
When a connection fails, clients typically encounter one of two errors: connection refused and connection timeout.
connection refused
The reasons generally include:
- The port the client is trying to connect to is incorrect.
- The domain name or IP address the client is trying to connect to is incorrect.
- If the client is using a domain name to connect, the domain may be pointing to the wrong server IP.
- The server may be using a CDN or other acceleration proxy, causing the actual IP to differ from the expected IP.
- The server is not started or the port is not being listened to.
- A network proxy software is in use.
- The server's listening IP and the accessed address are not in the same subnet. For example, if the server is listening on 127.0.0.1, the client can only connect through 127.0.0.1 and cannot connect through the local network IP or external IP. It is recommended to set the listening address to 0.0.0.0, allowing connections from local, internal, and external networks.
connection timeout
The reasons generally include:
- The server's firewall is blocking the connection; you may try temporarily disabling the firewall.
- If it is a cloud server, the security group may also be blocking the connection establishment; you need to open the corresponding port in the management backend.
- If using a panel such as Baota, you need to open the corresponding port in Baota.
- The server does not exist or is not started.
- If the client is using a domain name to connect, the domain may be pointing to the wrong server IP.
- The IP accessed by the client is the server's internal IP, and the client and server are not on the same local network.
cannot assign requested address
As a client, each time a connection is initiated, a temporary local port is required. A server typically has around 20,000 to 30,000 available temporary ports by default. If the number of connections made to a specific server exceeds this value, it will not be able to allocate an available port, resulting in this error.
You can increase the number of local temporary ports by changing the kernel parameter net.ipv4.ip_local_port_range in /etc/sysctl.conf, for example, setting it to 10000 65535 (which increases the available local ports to 55,535). Run sysctl -p to apply the changes.
Additionally, after a connection is closed, the connection enters the TIME_WAIT state and will still occupy the corresponding local port for a while. Initiating a large number of short-lived connections (over 20,000 to 30,000) in a short time may also lead to Cannot assign requested address. If this is the case, you can resolve it by configuring the kernel to quickly recycle TIME_WAIT; refer to Kernel Optimization.
Note
The local port limit applies only to clients. The server does not have a local port limit; as long as resources are sufficient, the server can maintain an unlimited number of connections.
Other Errors
If the error that occurs is neither connection refused nor connection timeout, it is generally due to the following reasons:
1. The communication protocol used by the client is inconsistent with that of the server.
For example, if the server uses the HTTP communication protocol, connecting with the WebSocket communication protocol will not work. If the client uses the WebSocket protocol, then the server must also use the WebSocket protocol. If the server is an HTTP service, then the client must access it using the HTTP protocol.
The principle here is similar to needing to use English to communicate with an English speaker and Japanese to communicate with a Japanese speaker. The language used here is analogous to the communication protocol; both sides (the client and the server) must use the same language to communicate; otherwise, communication will not be possible.
Common errors caused by inconsistent communication protocols include:
WebSocket connection to 'ws://xxx.com:xx/' failed: Error during WebSocket handshake: Unexpected response code: xxx
WebSocket connection to 'ws://xxx.com:xx/' failed: Error during WebSocket handshake: net::ERR_INVALID_HTTP_RESPONSE
Solutions:
From the above two error messages, it is clear that the client is using the WebSocket protocol to connect. The server must also be configured to use the WebSocket protocol for communication, such as in the following example:
If it is a GatewayWorker, the listening code should look like this:
// websocket protocol, so the client can connect using ws://... . The port number xxxx does not need to be changed.
$gateway = new Gateway('websocket://0.0.0.0:xxxx');
If it is Workerman, it should be:
// websocket protocol, so the client can connect using ws://... . The port number xxxx does not need to be changed.
$worker = new Worker('websocket://0.0.0.0:xxxx');