Troubleshoot Network Issues with dig and traceroute

By Kokil Thapa | Last reviewed: September 2026

Your API returns 502 errors, email bounces, or a Laravel app cannot reach a payment gateway. Before you restart services, you need facts. You can troubleshoot network issues with dig and traceroute to separate DNS failures from routing problems in minutes. These two CLI tools ship on every Linux server I maintain, including the Linux production hosts behind client portals and eCommerce sites. This guide walks through real commands, output you will actually see, and the order I use on live incidents.

What does dig tell you when DNS fails?

dig (Domain Information Groper) queries DNS servers directly. It shows which resolver answered, the record type returned, and how long the lookup took. Unlike GUI tools, dig output is scriptable and precise.

On a production Laravel application, a wrong A record often looks like an application bug. I've seen payment callbacks fail because staging DNS still pointed at an old IP after a migration. dig caught it in one command while the app logs only showed connection timeouts.

Basic dig commands for daily checks

Start with a simple lookup against your system resolver:

dig example.com A +short
dig example.com AAAA +short
dig example.com MX +short
dig example.com NS +short

The +short flag prints only the answer. Remove it when you need the full response, including the status line and ANSWER SECTION.

Query a specific nameserver when you suspect stale cache:

dig @ns1.example.com example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

If the authoritative server returns the correct IP but your local resolver does not, the problem is cache or a misconfigured /etc/resolv.conf entry.

Trace the full resolution chain

When a domain resolves inconsistently across regions, use recursive trace mode:

dig +trace example.com A

This walks from root nameservers down to the authoritative zone. You will see each delegation step. A break in the chain — missing glue records, wrong NS set, or a lame delegation — shows up clearly here.

For reverse DNS checks on mail servers, run:

dig -x 203.0.113.10 +short

Missing or mismatched PTR records cause deliverability problems that look like application bugs. I check PTR early on any SMTP incident.

Reading dig status codes

• NOERROR — query succeeded; check the ANSWER SECTION for records.
• NXDOMAIN — the name does not exist at that zone level.
• SERVFAIL — the resolver hit an error talking to upstream servers.
• REFUSED — the server rejected the query, often due to ACL rules.
• TIMEOUT — no response; suspect firewall rules on port 53 UDP/TCP.

Official reference for DNS response codes lives in ISC BIND dig documentation. Keep that page bookmarked when you parse unfamiliar flags.

How do you run traceroute on Linux and macOS?

traceroute sends packets with increasing TTL values. Each router along the path returns an ICMP time-exceeded message. You see hop number, router IP, and round-trip time. That tells you where packets stall before they reach the destination.

On Ubuntu 22.04 and 24.04 servers, the default package is traceroute. Some images ship tracepath instead, which needs no root for basic use.

Install and run traceroute

sudo apt update
sudo apt install traceroute
traceroute -n example.com
traceroute -n -T -p 443 example.com

The -n flag skips reverse DNS on each hop. That alone can cut runtime from minutes to seconds on slow resolvers. Use -T -p 443 for TCP-based traces when ICMP is blocked — common on cloud firewalls and some ISP networks in Nepal and abroad.

On macOS, use the built-in variant:

traceroute -n example.com
sudo traceroute -P TCP -p 443 example.com

Alternative tool mtr combines ping and traceroute with live updates. Install it when you need continuous sampling:

sudo apt install mtr-tiny
mtr -n -c 50 example.com

Interpreting traceroute output

A healthy trace ends at the target IP with stable millisecond values. Watch for these patterns:

1. Consistent high latency at one hop — congestion or geographic distance; compare at different times.
2. Complete stop after hop N — ACL drop, blackhole route, or ICMP disabled downstream.
3. Asterisks on middle hops only — often normal; many carriers rate-limit ICMP.
4. Routing loop — the same IP repeats across hops; contact the upstream provider.
5. Different path by protocol — run both ICMP and TCP traces to confirm.

The Linux traceroute man page documents flags for IPv6, source address selection, and packet size. Read it once; it saves guesswork later.

How do dig and traceroute work together during an outage?

DNS and routing are separate layers. Mixing them up wastes hours. I follow a fixed sequence on every incident, whether it is a booking platform API or a payment webhook on a WooCommerce store.

Step-by-step combined workflow

1. Confirm basic connectivity — ping -c 4 1.1.1.1 tests raw IP reachability without DNS.
2. Resolve the hostname — dig +short api.example.com A and compare to the expected IP from your deployment notes.
3. Trace to the resolved IP — traceroute -n $(dig +short api.example.com A | head -1).
4. Test the service port — nc -zv api.example.com 443 or curl -vI https://api.example.com.
5. Compare from a second vantage point — run the same commands from your laptop and from the server.

If step 1 fails but step 2 works, DNS is fine and routing is broken. If step 2 returns the wrong IP, fix DNS before you chase firewall rules. This split is the core reason you troubleshoot network issues with dig and traceroute as a pair.

Real scenario: API timeout after DNS change

On a client project, a third-party SMS API stopped responding after a nameserver migration. Application logs showed cURL error 28 — operation timed out. The quick checks looked fine because ping to the old IP still worked on some cached paths.

Running dig api.smsprovider.com A +short returned a new anycast range. traceroute -n to that IP stalled at hop 6 inside the provider's network. The fix was on their side, but we needed both outputs to prove it. Without dig, we might have rolled back working application code instead.

Similar splits appear when you troubleshoot Ubuntu network issues after a kernel or interface change. Always verify DNS before you edit netplan or restart systemd-networkd.

What is the difference between dig, nslookup, and host?

All three query DNS, but dig gives the most complete, parseable output for scripting and incident notes. Here is a practical comparison for engineers who troubleshoot network issues with dig and traceroute regularly.

For automation in CI or monitoring, prefer dig +short piped into your alert logic. I use the same pattern when validating DNS before Ansible playbooks provision PHP servers. A failed pre-flight dig stops the deploy before bad records propagate.

Store structured output with the JSON formatter tool when you paste dig logs into tickets. Clean formatting helps hosting support act faster.

What common dig and traceroute errors mean on production servers?

Production adds constraints that lab tutorials skip. Firewalls, Docker networks, split-horizon DNS, and CDN anycast all change what you see.

Dig errors and fixes

SERVFAIL on internal hostnames — the resolver cannot reach your private zone. Check that VPC DNS or bind9 forwarders are set in /etc/resolv.conf. On Docker, containers may inherit the host resolver or use Docker's embedded DNS at 127.0.0.11.

Correct dig but curl fails with SSL error — DNS is not your problem. Inspect the certificate SAN and expiry. This happens after partial migrations when the A record updated but the new server lacks the correct TLS chain.

Intermittent NXDOMAIN — often split-brain DNS. One nameserver holds stale zone data. Run dig @each-ns listed +short and compare.

Traceroute errors and fixes

All asterisks until destination — ICMP blocked end-to-end; switch to TCP trace on port 443 or 80.

Trace completes but HTTP times out — port-level block. Confirm with nc -zv host port. Security groups often allow ICMP but deny application ports.

Asymmetric routing — return path differs from forward path. traceroute only shows outbound hops. Use mtr over several minutes or ask the provider for a reverse trace.

How do you troubleshoot network issues from a production server in Nepal?

Local context matters. Nepal ISPs peer through multiple upstream paths. Latency to Singapore, Mumbai, or Hong Kong varies by time of day. A trace that looks odd at 10:00 may be normal at 02:00.

When a site on shared hosting or an EC2 instance fails only from Nepal, compare traces from a global VPS and from the local server. If the local trace stops at the ISP's gateway, open a ticket with the NOC. Attach plain-text dig +trace and traceroute -n output — not screenshots.

Checks before you blame the network

• Verify /etc/resolv.conf points at reliable resolvers, not a dead local forwarder.
• Confirm UFW or iptables allow outbound UDP/TCP 53 and the target service port.
• On Laravel queues, ensure the worker container shares the same DNS as the web container.
• After domain or hosting changes, wait for TTL expiry before retesting.
• Test IPv4 and IPv6 separately — broken AAAA records cause partial outages.

For legal-tech portals and booking systems I maintain, uptime depends on DNS as much as PHP code. A notary service portal that cannot resolve its SMTP relay fails silently on document notifications. Scheduled dig checks from cron catch drift early.

Pair these network checks with application monitoring. Read the Ubuntu network configuration guide when you need to fix the interface layer beneath DNS. For containerised apps, the Kubernetes network policies article covers pod-level blocks that mimic routing failures.

Commands I keep in a runbook snippet

HOST=api.example.com
echo "=== dig ==="
dig +trace $HOST A
echo "=== traceroute ==="
traceroute -n $(dig +short $HOST A | head -1)
echo "=== port check ==="
nc -zv $HOST 443
echo "=== curl ==="
curl -sI --connect-timeout 5 https://$HOST | head -5

Save that block as /usr/local/bin/check-host and run it after every deploy. It takes 30 seconds. It has saved full rollbacks on multiple sister sites that share a support and maintenance pipeline.

When latency — not total failure — is the complaint, pass results to your speed optimisation review. High TTFB from distant origin servers is a routing and CDN problem, not a CSS minification problem.

API integrations need the same discipline. Before debugging OAuth token refresh in Laravel, confirm the auth endpoint resolves and traces cleanly. The API development workflow I use treats network pre-checks as part of the integration spec, not optional ops work.

Key Takeaways

• Run dig +trace first to confirm DNS returns the expected IP before you edit application code or firewall rules.
• Use traceroute -n to the resolved IP; add -T -p 443 when ICMP is filtered on cloud or ISP paths.
• Separate DNS faults (wrong A record, NXDOMAIN, SERVFAIL) from routing faults (stall at a hop, port block) using the paired workflow.
• Capture plain-text dig and traceroute output in support tickets — providers act faster with reproducible evidence.
• Compare results from your server and your laptop to spot regional ISP or split-horizon DNS issues.
• Automate pre-flight DNS checks in deploy scripts and cron to catch record drift before users report outages.

People Also Ask

Do I need root to run dig and traceroute?

dig never requires root. Standard traceroute on Linux typically needs root or the CAP_NET_RAW capability because it sends raw ICMP or UDP probes. Use tracepath or mtr as non-root alternatives when your host restricts privileges.

Why does traceroute show asterisks but the site still works?

Many routers disable ICMP replies or rate-limit them for security. Middle-hop asterisks are common and often harmless. Focus on whether the trace reaches the destination IP and whether application ports respond with nc or curl.

Can dig troubleshoot email delivery problems?

Yes. Query MX, SPF (TXT at the root), DKIM (TXT at selector._domainkey), and DMARC (_dmarc TXT) records with dig. Verify PTR with dig -x on the sending IP. Missing or wrong records cause bounces that look like application bugs.

How long should I wait after fixing DNS?

Wait at least one full TTL cycle from the previous record. If TTL was 3600 seconds, allow up to an hour for global propagation. Use dig @8.8.8.8 +short and dig @1.1.1.1 +short to spot caches that still hold old data.

Build network diagnostics into your deployment process

Intermittent outages cost more than planned checks. When you troubleshoot network issues with dig and traceroute as a standard step — not a panic response — you isolate DNS and routing faults in minutes instead of hours. The commands are free, they run on any Linux server, and they produce evidence your hosting provider can use.

If your team needs runbooks, monitoring hooks, or post-migration DNS validation on production infrastructure, see the Linux system administration service or review related work in the project portfolio. For hands-on help wiring these checks into your deploy pipeline, contact us with your stack details and a sample hostname that failed — dig and traceroute output included.