How to Troubleshoot Intermittent Network Connectivity on a Linux Server

Intermittent network connectivity on a Linux server can be difficult to diagnose because the connection may work normally for several minutes before becoming slow, dropping packets, or timing out. Unlike a complete network outage, intermittent problems often leave few obvious signs and may affect only certain destinations, applications, or users.

For VPS administrators, developers, and hosting providers, these issues can cause website timeouts, failed API requests, unstable SSH sessions, database connection errors, and unexpected application failures.

The cause may be a local network interface issue, packet loss, routing instability, DNS resolution problems, firewall rules, connection limits, or an upstream network problem. In virtualized environments, the underlying host or provider network may also need investigation.

This guide explains how to troubleshoot intermittent network connectivity on a Linux server systematically, identify the likely source, apply appropriate fixes, and verify that the problem has been resolved.

1. Identify the Symptoms Before Changing Anything

Start by determining exactly how the connection fails. Different symptoms point toward different causes, so avoid changing network settings before collecting evidence.

Common symptoms include:

• SSH connections freezing or disconnecting unexpectedly.
• Websites becoming unreachable for short periods.
• API requests occasionally timing out.
• Packet loss appearing intermittently during network tests.
• Connections to one destination failing while other destinations remain reachable.
• DNS lookups occasionally taking too long.
• Network performance deteriorating during periods of high traffic.
• Applications reporting connection timeouts even though the server remains online.

First, determine whether the problem affects all network traffic or only a particular service.

For example, if SSH disconnects but a website hosted on the same server remains accessible, the issue may be specific to SSH, its configuration, or the path used by the affected client.

If the server can reach its gateway but cannot reach external destinations, investigate routing, upstream connectivity, firewall rules, and provider-side issues.

If external connectivity works but one application repeatedly times out, examine that application’s listening port, resource limits, connection handling, and logs.

Record the approximate time of each failure, affected destination, source IP address, and any error messages. This information becomes especially useful when comparing local logs with provider network records.

2. Check the Network Interface and IP Configuration

Begin with the server’s network configuration:

ip -br address

This displays network interfaces and their assigned IP addresses in a compact format.

Example:

lo               UNKNOWN        127.0.0.1/8
ens3             UP             192.0.2.10/24

The example uses a documentation-only IP address. Your server may use a public address, a private address, or multiple addresses depending on its configuration.

Check the interface state:

ip link show

Look for the expected interface and confirm that it is operational. An interface shown as DOWN requires investigation, but an interface marked UP does not guarantee that the physical or virtual network path is functioning correctly.

Next, inspect the routing table:

ip route show

On a typical server with a default IPv4 route, the output may include:

default via 192.0.2.1 dev ens3
192.0.2.0/24 dev ens3 proto kernel scope link

The actual gateway and subnet depend on the provider’s network configuration.

Check that the default route points to the expected gateway and interface. If the server has multiple network interfaces, policy routing, or additional IP addresses, inspect the complete configuration before making changes.

You can also check IPv6 routes:

ip -6 route show

A server may have working IPv4 connectivity while IPv6 connections fail, or the reverse. Test both protocols when the application or destination supports them.

Important: Do not randomly change interface addresses, gateways, or routes on a remote production server. An incorrect change can disconnect SSH and prevent further access. Use the provider console or another recovery method if available before making risky network changes.

3. Test Connectivity to the Default Gateway

The default gateway is a useful first diagnostic point because it helps distinguish local connectivity problems from failures farther along the network path.

Identify the gateway:

ip route show default

Then test its reachability:

ping -c 20 192.0.2.1

Replace 192.0.2.1 with the actual gateway address shown by your server.

Review the packet-loss percentage and response times. Repeated loss to a gateway that normally responds reliably can indicate a local interface issue, virtual network problem, or provider-side issue.

However, some gateways deprioritize or filter ICMP traffic. A lack of ping responses alone does not prove that forwarding traffic is failing.

If the gateway does not respond, compare the result with another available test, such as a connection to a known reachable destination or a provider-supported network diagnostic. Check interface counters and local logs before concluding that the gateway is faulty.

If the gateway responds consistently but external connections fail, move on to external connectivity and routing tests.

4. Measure Packet Loss and Latency

Packet loss occurs when network packets fail to reach their destination or return to the sender. Even intermittent loss can disrupt SSH, web applications, real-time communication, and TCP connections.

Start with a short ping test:

ping -c 50 1.1.1.1

For an extended observation, use:

ping -i 1 1.1.1.1

Stop the continuous test with Ctrl+C.

Look for:

• Missing replies.
• Sudden increases in round-trip time.
• Large variations in latency.
• Repeated periods of failure followed by recovery.

A single ping test is only a snapshot. Intermittent problems may require monitoring over several minutes or longer, particularly when they occur during peak traffic.

Test more than one destination. If one destination shows loss but another does not, the issue may involve the destination, its network path, or ICMP handling rather than the entire server connection.

Avoid treating one lost ping packet as proof of a serious fault. ICMP traffic can be deprioritized, and normal routing can produce occasional variation.

Use MTR to investigate the network path

MTR combines repeated traceroute-style path analysis with packet statistics. If it is installed, run:

mtr -rw -c 100 1.1.1.1

This performs a report-mode test with repeated probes.

On Debian or Ubuntu, install MTR if needed:

apt-get update
apt-get install mtr-tiny

On many RHEL-compatible distributions, the package is named mtr:

dnf install mtr

Package names and installation commands can differ by distribution.

When reading MTR results, distinguish packet loss at an intermediate hop from loss at the final destination. Some routers limit responses to diagnostic probes while forwarding normal traffic correctly.

If an intermediate hop shows loss but later hops and the destination do not, that intermediate-hop loss alone is not evidence of a forwarding problem.

More useful evidence is persistent loss that begins at a particular point and continues through subsequent hops, especially when it correlates with application failures. Even then, confirm the findings with other tests before assigning responsibility to a provider or network segment.

5. Check Whether DNS Resolution Is Intermittent

A server can have working network connectivity but still fail to reach applications by hostname because DNS resolution is slow or unsuccessful.

Compare hostname access with direct-IP connectivity where possible.

For example:

getent ahosts example.com

This uses the system’s configured name-resolution mechanism and may return multiple addresses.

To query a DNS server directly, use dig if it is installed:

dig example.com

Inspect the query time, returned status, and answer section.

You can also test a specific resolver:

dig @1.1.1.1 example.com

If direct resolver queries succeed but system lookups fail, investigate the server’s resolver configuration and local DNS services.

Review:

cat /etc/resolv.conf

On systems using systemd-resolved, also check:

resolvectl status

Some distributions manage resolver configuration automatically, so /etc/resolv.conf may be a symbolic link or generated file. Avoid editing it blindly without understanding which service manages it.

Compare several hostnames and, when appropriate, different DNS resolvers. A problem affecting only one domain may be related to that domain’s DNS records or authoritative nameservers rather than the server’s general connectivity.

Do not permanently replace the configured DNS resolver simply because one query fails. Confirm whether the resolver, network path, or target domain is responsible.

6. Inspect Network Interface Error Counters

Linux network interfaces maintain counters that can reveal packet errors, dropped packets, and other signs of trouble.

Run:

ip -s link show

Example:

RX: bytes  packets  errors  dropped  missed  mcast
TX: bytes  packets  errors  dropped  carrier collsns

The exact fields and layout depend on the interface and kernel.

Pay attention to receive errors, transmit errors, dropped packets, and carrier-related errors where available.

A counter’s absolute value is not always enough to diagnose a current issue. Counters may include events from before the incident. Record the output, wait while the problem is occurring, and run the command again to compare the changes.

For more detailed statistics, use:

ethtool -S ens3

Replace ens3 with the actual interface name. Some virtual network interfaces do not expose all hardware-level counters, and the available fields vary by driver and provider.

If counters increase rapidly during an outage, investigate the interface, virtual NIC, driver, host network, or upstream path as appropriate. On a managed VPS, some of these components can only be examined by the hosting provider.

7. Check for Network Saturation

Intermittent connectivity can result from network congestion or excessive traffic. A server under heavy transfer load may experience increased latency, timeouts, or dropped packets.

Check interface statistics:

ip -s link show

For live bandwidth monitoring, tools such as iftop or nload can help, if installed and supported by your environment.

For example, with nload:

nload

These tools can help identify unusually high inbound or outbound traffic, but they do not by themselves prove that the network is saturated.

Also inspect system resource usage:

top

A server that is overloaded by CPU-intensive tasks, excessive connections, or other resource constraints may appear to have a network problem when the bottleneck is actually application processing.

If network traffic regularly approaches the VPS plan’s available bandwidth or provider limits, investigate the traffic source, caching, application behavior, and hosting plan requirements.

Do not assume every VPS provider applies the same bandwidth policy. Check the actual service terms and monitoring information for your server.

8. Investigate Firewall Rules and Connection Tracking

Firewall rules can interrupt connectivity if they reject, drop, or rate-limit certain traffic. Review the active firewall configuration before making changes.

On systems using UFW:

ufw status verbose

On systems using nftables:

nft list ruleset

On systems using iptables:

iptables -L -n -v

Some systems use more than one management layer, while others use a different firewall framework. Check which configuration is active before interpreting the output.

Look for rules affecting the source IP address, destination port, protocol, or connection state associated with the failure.

Pay attention to counters that increase during the incident. A rule’s packet or byte counters can help determine whether traffic is matching that rule.

Check connection tracking where applicable

Linux systems using Netfilter connection tracking may encounter connection-tracking table pressure under certain workloads.

If the relevant kernel interfaces are available, inspect the current and maximum entries:

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

These files may not exist if connection tracking is unavailable or the relevant module is not loaded.

If the current count repeatedly approaches the configured maximum and kernel logs show connection-tracking table exhaustion, investigate the connection pattern and firewall configuration. Increasing limits without understanding the cause can increase memory consumption and conceal the underlying issue.

Avoid flushing firewall rules or disabling the firewall as a troubleshooting shortcut on a remote server. Doing so can expose services or lock you out.

9. Check for TCP Connection Problems

Some connectivity issues affect particular TCP services rather than the entire network.

For example, a server may respond to ping while connections to its web service time out. This can happen when the service is not listening, a firewall drops traffic, the application is overloaded, or the network path is failing.

Check whether the expected service is listening:

ss -lntp

To inspect established TCP connections:

ss -tan

To test a specific remote TCP port, use Netcat if installed:

nc -vz example.com 443

Replace the hostname and port with the actual destination.

A successful connection confirms that a TCP connection could be established at the time of the test. It does not guarantee that the application is healthy or that connectivity will remain stable.

For a server hosting a website, test from both sides when possible:

• From the server to the destination.
• From an external system to the server’s service port.

If outbound connections fail but inbound connections work, investigate the outbound route, firewall policy, remote service, and provider restrictions. If only inbound access fails, check the server’s listening service, inbound rules, public IP configuration, and external network path.

10. Review Kernel and System Logs

Kernel messages may contain evidence of interface resets, driver errors, link changes, or network-related resource problems.

Inspect recent kernel messages:

journalctl -k --since "30 minutes ago"

Search for potentially relevant messages:

journalctl -k --since "1 hour ago" | grep -Ei \
'link is down|link is up|NETDEV WATCHDOG|transmit queue|reset|firmware|network'

The wording varies by kernel, driver, and distribution, so the absence of these exact phrases does not rule out a network issue.

Check system service logs as well:

journalctl --since "30 minutes ago" -p warning

Compare the timestamps with the recorded connectivity failures.

If a network service or connection manager is responsible for configuring the interface, inspect its logs and service status. Service names differ between distributions and network-management setups, so identify the service actually used by your server before restarting anything.

A recurring interface reset or link-state change that coincides with the outage is more useful evidence than an unrelated warning from several hours earlier.

11. Investigate Routing and MTU Problems

Routing problems can affect specific destinations or network paths while leaving other connections unaffected.

Check the route selected for a destination:

ip route get 1.1.1.1

For IPv6, use an IPv6 destination and inspect the corresponding route.

If the server has multiple interfaces or policy-routing rules, inspect:

ip rule show
ip route show table all

Compare the selected route with the intended network configuration. Avoid deleting or replacing routes until you understand how the server reaches its gateway and any private networks.

Check the MTU

An incorrect Maximum Transmission Unit (MTU) can cause problems when packets exceed what a network path can carry without fragmentation. Some connections may work while others stall, particularly when Path MTU Discovery is disrupted.

Inspect the interface MTU:

ip link show ens3

Replace ens3 with your interface.

For IPv4, a diagnostic ping with a 1472-byte payload and the don’t-fragment flag can help test a typical 1500-byte path:

ping -M do -s 1472 -c 4 1.1.1.1

This test is not universal. The destination must respond appropriately, and tunnels or smaller path MTUs may require a different payload size. ICMP filtering can also make the result inconclusive.

If MTU problems are suspected, compare tests using smaller payloads and review the network’s actual MTU requirements. Do not change the interface MTU arbitrarily on a remote production server.

12. Determine Whether the Problem Is Inside or Outside the VPS

A VPS administrator does not always have visibility into the entire network path. The guest operating system may look healthy even when the underlying host, virtual switch, physical network, or upstream provider is experiencing a problem.

Use multiple independent observations to narrow the source.

Observation	Possible direction for investigation
Interface errors increase during outages	Virtual NIC, interface, driver, or host network
Gateway tests fail alongside other local network symptoms	Local configuration or provider-side network
Gateway responds, but several external destinations fail	Routing, upstream connectivity, or filtering
Only one destination fails	Destination service or a specific network path
DNS fails while direct-IP tests succeed	Resolver configuration or DNS path
Only one application fails	Application, port, firewall, or resource limits
Guest diagnostics look normal but outages persist	Provider-side investigation may be necessary

These are diagnostic clues, not definitive conclusions. For example, an intermediate router may drop ICMP replies while forwarding application traffic normally.

If the evidence points toward the provider network, open a support ticket and include:

• The approximate start and end times of each incident, including timezone.
• The affected source and destination IP addresses.
• Whether IPv4, IPv6, or both are affected.
• Packet-loss and latency test results.
• MTR reports collected during the issue.
• Network interface counters before and during the incident.
• Relevant kernel log messages.
• Whether the problem affects all destinations or only specific services.

Do not include passwords, private keys, access tokens, or other secrets in diagnostic reports.

13. Monitor Connectivity to Catch Intermittent Failures

A single successful test cannot rule out an intermittent problem. If the issue appears only occasionally, collect evidence over a longer period.

A simple ping log can help establish when reachability changes:

ping -D 1.1.1.1 | tee -a ping-test.log

The -D option adds timestamps on implementations that support it. Run this in a controlled diagnostic session and stop it when enough evidence has been collected.

Remember that the destination may filter ICMP, so a ping log should not be the only monitoring method. For application-specific issues, monitor the actual service as well.

For example, an HTTPS endpoint can be tested with:

curl -sS -o /dev/null \
  -w 'HTTP %{http_code} | Connect %{time_connect}s | Total %{time_total}s\n' \
  --connect-timeout 5 https://example.com/

Use an endpoint that you are authorized to test. HTTP status codes and response times help distinguish connection failures from slow application responses, although they do not independently identify the root cause.

For persistent monitoring, use an established monitoring system that records reachability, latency, and service health over time. Set alert thresholds according to the workload rather than treating every isolated packet loss event as an outage.

14. Apply the Fix Based on the Evidence

After identifying a likely cause, make a targeted correction rather than applying multiple changes simultaneously.

Depending on the findings, the appropriate action may be to:

• Correct a verified network configuration error.
• Investigate and repair a faulty virtual interface or provider-side network issue.
• Fix a DNS resolver or domain-specific DNS problem.
• Adjust an incorrectly configured firewall rule.
• Reduce excessive network traffic or connection pressure.
• Correct an MTU mismatch after confirming the required path MTU.
• Repair or restart an affected application after reviewing its logs.
• Ask the hosting provider to investigate a problem outside the guest operating system.

Before changing network configuration, save the current settings and ensure that an alternate console or recovery path is available. If possible, apply changes during a maintenance window.

Restarting the network service may terminate active connections, and a mistake can disconnect the server completely. Avoid restarting it simply because connectivity is intermittent when the actual cause has not been identified.

After each change, repeat the same tests that originally demonstrated the problem. This helps determine whether the change improved the situation or introduced a new issue.

15. Verify the Fix and Prevent Recurrence

Once connectivity appears stable, repeat the original diagnostics:

ip -s link show
ip route show
ping -c 50 1.1.1.1

Also repeat relevant DNS queries, TCP connection tests, and application-level checks.

Compare the new results with the evidence collected during the incident. Verify that packet loss, latency spikes, interface counters, or application timeouts no longer show the same failure pattern.

Continue monitoring for a reasonable period, especially if the issue was previously observed only during peak traffic or at specific times.

To reduce future incidents:

• Monitor network reachability and service health.
• Keep operating system and network-driver updates under a controlled maintenance process.
• Review interface errors and system logs after recurring incidents.
• Track bandwidth and connection usage.
• Maintain a documented network configuration and recovery method.
• Keep a record of provider incidents and relevant diagnostic reports.

Troubleshooting intermittent network connectivity on a Linux server requires more than checking whether the server responds to ping. The key is to isolate the failure by examining interface configuration, packet loss, DNS, routing, firewall rules, TCP connections, system logs, and provider-side network conditions.

Collect evidence while the problem is occurring, change one thing at a time, and verify the result using the same tests that exposed the issue. If the server’s configuration appears healthy but connectivity still fails, detailed diagnostic evidence can help the hosting provider investigate the underlying network path.

For workloads that require reliable connectivity, review your infrastructure requirements and the available ServerNext VPS hosting options when evaluating your server setup.