Dedicated Server Timeout: Causes, Fixes & How to Prevent Connection Issues

A server timeout means that a client or a server stopped waiting for a response because none arrived within a set time limit. The connection is then dropped, and the side that gave up reports an error such as "Connection timed out", "408 Request Timeout" or "504 Gateway Timeout".

A dedicated server timeout occurs when a client attempts to connect to a server but receives no response within the expected time window, and the connection is dropped. Timeout errors are among the most common issues reported by server owners and players connecting to game servers, and they have a wide range of causes: firewall misconfiguration, network instability, overloaded server resources, or incorrect port settings. This guide explains what dedicated server timeouts are, why they happen, and how to fix them. If you have not set up your server yet, start with our Linux server configuration guide.

What Is a Dedicated Server Timeout?

A timeout is a built-in mechanism that terminates a connection attempt after a defined period with no response. When you see an error like "Connection timed out", "Timed out waiting for host", or "Connection timeout", it means:

• Your client sent a connection request (TCP SYN or UDP packet) to the server's IP and port.
• The server, or a firewall between you and the server, did not respond within the timeout window.
• The client gave up and reported a timeout error.

This is different from a "Connection refused" error, which means the server actively rejected the connection (port closed or service not running). A timeout typically points to a network-level block or an unresponsive server.

On the web, the HTTP standard (RFC 9110) defines two timeout status codes. 408 Request Timeout means the server did not receive a complete request within the time it was prepared to wait. 504 Gateway Timeout means a proxy or gateway, such as Nginx in front of PHP-FPM, did not get a timely response from the upstream server behind it.

What Causes Dedicated Server Timeout Errors?

1. Firewall blocking the port

The most frequent cause. If the server's firewall (UFW, iptables, firewalld, or Windows Firewall) does not have a rule allowing incoming traffic on the required port, the connection attempt is blocked. With UFW, the default incoming policy is deny, which ignores the packet instead of telling the sender: the client hears nothing and times out. firewalld behaves differently: by default, a zone rejects unmatched traffic, so the client usually gets an immediate error rather than a timeout. Our UFW firewall setup guide shows how to set default rules and open each port.

2. Router / NAT port forwarding not configured

If your dedicated server is behind a router (for example in a home lab or self-hosted setup), you need to forward the game or application port from the router's public IP to the server's private IP. Missing or incorrect port forwarding rules are a common cause of timeout errors for game servers. On a server with its own public IP, no router is involved, and port forwarding on the server comes down to a firewall rule.

3. Server overload or unresponsive service

When a server is under heavy load, whether from high CPU usage, memory exhaustion, or a hung process, it may fail to respond to incoming connections in time, triggering a timeout on the client side. The service is running but too busy to accept new connections.

4. Wrong IP address or port

A simple but easy-to-miss configuration error: connecting to the wrong public IP address, or using the wrong port number. Always verify the server's current public IP (on a home connection with a dynamic IP, it can change when the router reconnects) and confirm the application is listening on the expected port.

5. ISP or upstream network issue

Occasionally, packet loss or routing issues between your ISP and the server's data centre cause connection timeouts that are outside your control. These are typically transient and resolve within minutes.

How to Fix a Dedicated Server Connection Timeout: Step by Step

Step 1: Verify the server is reachable

From your local machine, ping the server's public IP to check basic network connectivity:

ping YOUR_SERVER_IP

If ping replies, the server is reachable. If ping times out, the issue is at the network level (firewall blocking ICMP, or server is down). Open the KVM console from the OVHcloud Control Panel to check whether the server is running: our IPMI guide explains how console access works and notes that availability varies by model.

Step 2: Check which ports are open

On the server, verify which ports are actively listening:

sudo ss -tlnup

# or:

sudo netstat -tlnup

Confirm your application is listening on the correct port. If it is not listed, the service is not running: start it with sudo systemctl start your-service.

Step 3: Check firewall rules

On Ubuntu/Debian with UFW:

sudo ufw status verbose

On AlmaLinux/RHEL with firewalld:

sudo firewall-cmd --list-all

If the required port is not in the allowed list, add it. For example, to open UDP port 7777 (common for game servers):

sudo ufw allow 7777/udp    # UFW

sudo firewall-cmd --permanent --add-port=7777/udp && sudo firewall-cmd --reload    # firewalld

Step 4: Test port accessibility from outside

For a TCP port (SSH, HTTP, databases), use an online port checker (e.g., portchecker.co) or run from another machine:

nc -zv YOUR_SERVER_IP 443

By default this tests TCP, so it cannot check a UDP game port such as 7777: according to the nc manual, a UDP scan with -uz "will always report success" whatever the state of the target. For UDP, connect with the game client and watch on the server whether packets arrive:

sudo tcpdump -ni any udp port 7777

If packets show up in tcpdump but the game still times out, the problem is on the server (firewall or service). If nothing arrives, the traffic is blocked before it reaches the machine.

If the port is still unreachable after opening the server firewall, check whether the OVHcloud Edge Network Firewall has rules on your IP in the Control Panel. You can enable or disable it at any time, except during a DDoS attack, when it is activated automatically and its rules apply even if you had disabled it. It cannot open ports (that remains the job of the operating system firewall), and OVHcloud notes it may be unavailable or limited on Eco servers, the product line Kimsufi belongs to.

Step 5: Restart the service and check logs

If the port is open but connections still time out, restart the service and inspect the logs:

sudo systemctl restart your-service

sudo journalctl -u your-service -n 50

✅ Expected result After opening the correct port in your firewall and restarting the service, clients should be able to connect without timeout errors.

Troubleshooting: Common Timeout Errors and Fixes

Database note: MySQL decides where it listens with bind-address in my.cnf, and PostgreSQL with listen_addresses in postgresql.conf, whose default is localhost (local connections only).

How to Improve Server Connection Stability

• Keep services updated: outdated software can have bugs that cause connection drops or unresponsive states.
• Monitor server load: use htop or install Netdata for real-time monitoring. If CPU or RAM is consistently maxed out, consider upgrading your server plan.
• Configure application-level timeout values: for web applications, tune timeout settings in your web server config (e.g., the Timeout directive in Apache, proxy_read_timeout in Nginx) to match your application's response times. The reference values are in the next section.
• Enable connection keep-alives: this reduces the overhead of establishing new connections for each request, improving stability under load. In Apache, KeepAlive is already On by default.
• Use DDoS protection: Kimsufi's built-in anti-DDoS protection filters volumetric attacks at the network edge, preventing your server from being overwhelmed by malicious traffic that would otherwise cause timeout errors for legitimate users.

Timeout Settings Reference: Defaults From the Official Docs

Each layer has its own timer. Before changing one, check which layer reported the timeout. The defaults below are taken from each project's official documentation.

Nginx

Set in an http, server or location block (proxy module, FastCGI module):

• proxy_read_timeout, default 60s: maximum wait between two reads from the proxied server, not a limit on the whole response.
• proxy_connect_timeout, default 60s: time allowed to establish the connection to the proxied server. It usually cannot exceed 75 seconds.
• proxy_send_timeout, default 60s: maximum wait between two writes when sending the request to the proxied server.
• fastcgi_read_timeout, default 60s: the same as proxy_read_timeout, for a FastCGI backend such as PHP-FPM.

Apache

Set in the server config or a virtual host (core directives):

• TimeOut, default 60 seconds: how long Apache waits for I/O, when reading from or writing to the client, for CGI output, and for mod_proxy when ProxyTimeout is not set.
• KeepAliveTimeout, default 5 seconds: how long Apache waits for the next request on a persistent connection.

SSH

Set in /etc/ssh/sshd_config on the server (sshd_config) or in your local SSH client config (ssh_config):

• ClientAliveInterval (server), default 0, meaning disabled: seconds of client inactivity before sshd sends a keepalive message through the encrypted channel.
• ClientAliveCountMax (server), default 3: number of unanswered keepalive messages before sshd disconnects the client.
• ServerAliveInterval (client), default 0: the same mechanism from your side, useful when a home router drops idle sessions.

Linux TCP stack

Kernel settings, read and changed with sysctl (kernel ip-sysctl documentation):

• net.ipv4.tcp_keepalive_time, default 2 hours: idle time before TCP sends keepalive probes, on sockets that enable keepalive.
• net.ipv4.tcp_keepalive_intvl and net.ipv4.tcp_keepalive_probes, default 75 seconds and 9 probes: a dead peer is dropped about 11 minutes after probing starts.
• net.ipv4.tcp_syn_retries, default 6: SYN retransmissions on an outgoing connection, which ends in a timeout after about 131 seconds.

Two practical points

• SSH sessions that freeze when idle: the usual culprit is a router or firewall dropping an idle connection. Set ClientAliveInterval 60 on the server (or ServerAliveInterval 60 in your local ssh config): with the default ClientAliveCountMax of 3, the session stays alive and a truly dead client is dropped after about three minutes. Unlike TCPKeepAlive, these messages travel inside the encrypted channel and cannot be spoofed.
• 504 Gateway Timeout behind Nginx: proxy_read_timeout and fastcgi_read_timeout count the time between two reads, not the total response time. Raising them hides a slow backend rather than fixing it, so look at the PHP-FPM or application logs first.

Conclusion

Dedicated server timeout errors are almost always caused by a firewall blocking a port, a misconfigured service, or a server under excessive load. Working through the five diagnostic steps in this guide, checking reachability, open ports, firewall rules, external port access, and service logs, resolves the vast majority of timeout issues within minutes. For broader server management, see our Linux dedicated server guide.

Need a reliable dedicated server? Kimsufi dedicated servers include built-in DDoS protection, full root access, and unmetered bandwidth, starting at $11.10/month.

FAQ