Blog

Broken connectivity rarely arrives with a helpful label. One minute a deployment is healthy, the next minute an API cannot reach a database, a webhook times out, or a server responds from your laptop but not from production. The fastest fix usually comes from slowing down for a few minutes and testing the path in layers.

Start by confirming what machine, network, and public address you are actually using. A quick IP address location lookup can catch surprises such as VPN routing, proxy exits, wrong ISP paths, or cloud instances appearing from a different region than expected.

Start With the Exact Failure

Before running commands, define the failure as precisely as possible. “The app is down” is too broad. “The API container cannot connect to PostgreSQL on port 5432 from the staging subnet” is useful. Good network debugging is mostly about removing vague language. Write down the source, destination, protocol, port, environment, and timing. If the problem only appears after deployment, note the image tag, host, subnet, and security group involved.

This matters because different failures need different tools. A browser timeout is not the same as a DNS error. A refused connection is not the same as a dropped packet. A slow first byte is not the same as packet loss. If you use curl -v, nc, logs, and browser developer tools together, you can usually sort the error into name resolution, routing, transport, TLS, or application behavior.

Prove the Local Network Is Sane

Begin on the machine that reports the issue. Check whether it has the expected IP address, gateway, DNS resolver, and route table. On Linux, ip addr, ip route, and resolvectl status are often enough to find obvious mistakes. In containers, run the same checks inside the container, not only on the host. A container can have a clean host network but still fail because of bridge rules, missing DNS config, or an isolated network.

For developer machines, VPN clients and local proxies are common causes. A route may send private ranges through a tunnel, while public traffic exits normally. A proxy may work for browsers but not for CLI tools. If you have been tuning network performance, the same discipline used for IP tracking tools also helps here: identify the real path before assuming the service is broken.

Use DNS Tests Before Ping

Many people start with ping, but DNS should often come first. If the hostname resolves to the wrong address, reachability tests may only prove that the wrong target is alive. Run dig example.com or nslookup example.com and check the returned A, AAAA, CNAME, and TTL values. Compare results from your local resolver, a public resolver, and the resolver used inside your production environment.

Split-horizon DNS can make this tricky. Internal users may resolve a private IP, while public users resolve a load balancer. Cloud environments may use private hosted zones, search domains, or service names that only work inside a cluster. If IPv6 is enabled, an AAAA record can also change behavior. Some clients prefer IPv6, then fail if the IPv6 route is incomplete. Test both address families where relevant.

A Practical Order for Connectivity Checks

1. Check the source.
   Confirm the host, container, or pod that is making the request. Do not test from your laptop if the failing request starts in production.
2. Resolve the name.
   Use DNS tools to confirm the hostname maps to the expected IP address. Pay attention to CNAME chains and cached values.
3. Test the port.
   Use nc -vz host port, telnet, or curl -v. Ping only tests ICMP, not whether TCP or UDP traffic works.
4. Trace the route.
   Run traceroute or tracepath to see where packets stop or take an unexpected path. Compare working and failing networks.
5. Inspect filters.
   Check host firewalls, cloud security groups, network ACLs, container policies, and service-level allowlists.

Read Ping Results Carefully

ping is useful, but it is easy to overread. A failed ping does not always mean the host is down. Many firewalls block ICMP while allowing HTTP, SSH, or database traffic. A successful ping only proves that ICMP replies came back. It does not prove that your application port is reachable, authenticated, or healthy.

Use ping for basic latency and packet loss signals. If latency jumps from 10 ms to 300 ms after a network change, the route may have shifted. If packet loss appears only from one office or cloud region, focus on that path. If ping works but the app fails, move to port checks and protocol-level tests instead of repeating the same command.

Trace the Path Without Guessing

Routing problems often hide between networks. A request may leave your host correctly, pass through several routers, then vanish at a peering boundary or firewall. Traceroute-style tools show each hop that responds along the path. The output is not perfect, since routers may rate limit or ignore probes, but it is still valuable for comparing good and bad paths. The basic behavior of traceroute makes it useful for finding where a path changes or stops.

Run traces from both directions if you can. Outbound traffic may take a different route than inbound traffic. In cloud systems, asymmetric routing can cause strange failures when return packets do not come back through the expected firewall or NAT gateway. If only one region fails, compare traceroute output from that region against a healthy one.

Check Firewalls at Every Layer

Connectivity can be blocked in more places than expected. A Linux host may use UFW, iptables, nftables, or firewalld. A cloud account may have security groups, subnet ACLs, load balancer rules, and managed database allowlists. Kubernetes may add network policies. The application itself may reject traffic based on origin IP, host headers, or TLS settings.

Do not assume one open rule opens the whole path. A database security group may allow the app subnet, but the app host firewall may still block outbound traffic. A load balancer may accept port 443, while the target group fails health checks on port 8080. If you already manage Linux packet filtering, a clear habit from UFW and iptables applies here: name the allowed source, destination, protocol, and port before changing rules.

Use WHOIS and Public Records for External Targets

For third-party APIs, WHOIS and public DNS records can explain failures that internal tools cannot. A vendor may move traffic to a new provider, change IP ranges, add IPv6, or shorten DNS TTLs during migration. If your allowlist still contains old addresses, your app may fail only after DNS cache expiry. WHOIS data can also help confirm ownership when a domain appears suspicious or unexpectedly resolves to a new network.

Do not build fragile allowlists from one lookup result. Many SaaS platforms use CDNs and rotating address pools. Prefer vendor-published IP ranges when available. If you must inspect live DNS, collect several results over time and from multiple resolvers before making a firewall change.

Signals That Point to the Root Cause

Patterns matter more than single outputs. One failed command may be noise. Several related signals usually tell a story. During an incident, collect enough evidence to separate network trouble from application trouble.

• DNS mismatch: staging and production resolve the same hostname to different targets.
• Port closed: ping works, but nc reports refused or timed out connections.
• Regional failure: one cloud region fails while another succeeds using the same code.
• VPN-only issue: traffic works outside the tunnel but fails when private routes are active.
• Recent change: a firewall, DNS, deploy, or certificate update happened shortly before failures started.

Keep a Small Debug Script Ready

Repeated incidents become easier when you have a small script that captures the same evidence every time. It can print the date, hostname, local IP addresses, route table, resolver config, DNS result, curl timing, and traceroute output. Store the script with your runbooks or internal tooling. During an outage, consistent output saves time and reduces guesswork.

For application teams, add network checks to deployment validation. Test database ports, cache endpoints, message brokers, and key third-party APIs before sending traffic to new instances. A failed preflight check is much cheaper than a production rollback after users hit timeouts.

Make Each Test Narrower Than the Last

Efficient IP connectivity debugging is not about running every tool you know. It is about narrowing the failure with each test. Confirm the source, resolve the destination, test the port, inspect the route, then check every filtering layer. If the evidence points back to the application, you can debug code with more confidence because the network path has already been cleared.

The best teams treat this as a repeatable workflow, not a heroic incident ritual. They collect clean command output, compare working and failing paths, and document the fix after the issue is resolved. That habit turns a messy timeout into a readable trail, and the next connectivity problem becomes faster to solve.