Error 209: SOCKET_TIMEOUT
This error occurs when a network socket operation (reading or writing) exceeds the configured timeout period. It indicates that data could not be sent to or received from a network connection within the allowed time, typically due to network issues, slow client response, or overloaded connections.
Most common causes
-
Network connectivity issues
- Network latency or packet loss
- Unstable network connection
- Firewall or network security appliance delays
- Network congestion between client and server
-
Client not reading data fast enough
- Client application blocked or frozen
- Client receive buffer full
- Client is processing slower than server sending
- Client-side timeout shorter than data transfer time
-
Large result sets
- Query returning huge amount of data
- Client unable to consume data at required rate
- Network bandwidth insufficient for data volume
- No
LIMITclause on queries returning millions of rows
-
Slow or overloaded client
- Client CPU or memory exhausted
- Client garbage collection pauses
- Client application not responsive
- Too many concurrent connections on client
-
TCP window exhaustion
- Client TCP receive window fills up (window size = 1)
- Client not acknowledging packets fast enough
- TCP backpressure from slow consumer
-
Load balancer or proxy timeout
- Intermediate proxy timing out connection
- Load balancer idle timeout
- Service mesh timeout configuration
Common solutions
1. Increase timeout settings
2. Reduce result set size
3. Use compression
For client connections:
4. Optimize client data consumption
5. Check network connectivity
6. Configure TCP keep-alive
Client-side (Linux):
7. Increase client buffer sizes
Common scenarios
Scenario 1: Timeout writing to socket
Cause: Client not consuming data fast enough, TCP window exhausted.
Solution:
- Add
LIMITto reduce result size - Enable compression
- Increase
send_timeoutsetting - Optimize client to consume data faster
- Check client isn't blocked or frozen
Scenario 2: Distributed query socket timeout
Cause: Remote shard not responding or network issue between nodes.
Solution:
Scenario 3: Client receive window = 1
Cause: Client application stopped reading from socket.
Solution:
- Check client application health
- Ensure client is actively consuming results
- Verify client has sufficient resources (CPU, memory)
- Add rate limiting on server side
Scenario 4: Network problems
Cause: Network connectivity issues, packet loss, or routing problems.
Solution:
- Diagnose network with
ping,traceroute,mtr - Check firewall rules and network ACLs
- Verify network bandwidth is sufficient
- Check for network security appliances causing delays
Scenario 5: External network problems
Cause: Issues with internet connectivity or cloud provider network.
Solution:
- Check cloud provider status page
- Verify VPC/network configuration
- Test connectivity from multiple locations
- Contact network or cloud support
Prevention tips
- Set appropriate timeouts: Match client and server timeout settings
- Use LIMIT clauses: Prevent queries from returning too much data
- Enable compression: Reduce network bandwidth requirements
- Monitor network health: Track latency and packet loss
- Optimize queries: Return only needed data
- Stream results: Process data as it arrives, don't buffer all
- Configure TCP properly: Set appropriate keep-alive and buffer sizes
Debugging steps
-
Check recent socket timeout errors:
-
Check current timeout settings:
-
Monitor active connections:
-
Check network statistics:
-
Capture network traffic (if needed):
-
Check query result size:
Special considerations
For HTTP interface:
- HTTP connections can be affected by load balancer timeouts
- Check
http_send_timeoutandhttp_receive_timeoutsettings - Load balancers may have their own timeout configurations
For distributed queries:
- Timeout can occur when sending results between nodes
- Each hop adds latency
- Use
send_timeoutandreceive_timeoutfor inter-node communication
For large result sets:
- Consider using
LIMITand pagination - Use
SELECTonly needed columns, notSELECT * - Apply filters to reduce data volume
- Consider materialized views for aggregations
TCP window size = 1:
- This is a strong indicator that the client stopped reading
- The server has data to send, but the client buffer is full
- Usually client-side issue, not ClickHouse issue
Timeout-related settings
Query-level settings:
Client-side configuration
Python (clickhouse-connect):
JDBC:
HTTP:
Distinguishing from TIMEOUT_EXCEEDED (159)
SOCKET_TIMEOUT (209): Network-level timeout during data transferTIMEOUT_EXCEEDED (159): Query execution time limit exceeded
SOCKET_TIMEOUT is about network I/O, while TIMEOUT_EXCEEDED is about query execution time.
If you're experiencing this error:
- Check if client is actively consuming results
- Verify network connectivity and latency
- Add
LIMITto queries returning large results - Enable compression to reduce bandwidth usage
- Increase
send_timeoutandreceive_timeoutif appropriate - Monitor client application health and resource usage
- Check for TCP window size dropping to 1 (indicates client not reading)
- Verify no intermediate proxies or load balancers timing out
- Test with simpler/smaller queries to isolate the issue
Related documentation: