🌐 Terminal Simulator — Module 4

Networking & Connectivity Troubleshooting

The API returns 502 Bad Gateway. Is it DNS, firewall, or a port conflict? Debug layer by layer.

Module Progress0/8 steps
STEP 1 / 8
ping

Is It Even Alive? — Basic Reachability Check

Real-World Scenario

Users are reporting "Connection timed out" errors from the web application. The app connects to a PostgreSQL database at 192.168.1.50. Before diving into application logs, the FIRST thing a senior engineer checks is basic network reachability. Can the app server even talk to the DB server? `ping` sends ICMP echo requests — if you get replies, Layer 3 connectivity is working.

Technical Breakdown

`ping` sends ICMP ECHO_REQUEST packets and listens for ECHO_REPLY. `-c 4` limits to 4 packets (without it, ping runs forever on Linux). The output shows round-trip time (RTT) in milliseconds — anything under 1ms on a LAN is normal, >100ms on LAN indicates network issues. Packet loss % is critical: 0% = healthy, any loss = investigate. `ping` tests Layer 3 (IP) connectivity only — a host can be "pingable" but have its application port down.

-c NSend exactly N packets, then stop (essential on Linux).
-i NWait N seconds between packets (default: 1 second).
-W NTimeout — wait N seconds for each reply.
-s SIZESet packet size in bytes (default: 56). Useful for MTU testing.

Your Task

Check if the database server at 192.168.1.50 is reachable. Type: ping -c 4 192.168.1.50

devops@prod-server-03 — bash
devops@prod-server:~$

Quick Guide: Network Debugging

Understanding the basics in 30 seconds

How It Works

  • ping tests Layer 3 (IP) reachability — 0% packet loss = network is OK
  • curl -I fetches HTTP headers only — check status codes without downloading body
  • ip addr shows interface IPs — modern replacement for deprecated ifconfig
  • ss -tuln lists listening TCP/UDP ports — find port conflicts instantly
  • dig queries DNS directly — verify hostname resolution is working
  • traceroute maps the network path — find where packets are being dropped
  • nc -zv tests specific port connectivity — definitive firewall test
  • grep filters massive log files — find connection errors in seconds

Key Benefits

  • Systematic layer-by-layer network debugging (OSI model approach)
  • Instant API health verification with curl -I (headers only)
  • Quick port conflict detection when services fail to start
  • DNS troubleshooting to pinpoint resolution failures
  • Firewall verification with targeted port testing
  • Efficient log analysis to find the root cause fast

Real-World Uses

  • Debugging failed database connections in microservice architectures
  • Verifying API endpoint health after deployments
  • Finding IP addresses for firewall whitelist configuration
  • Diagnosing "Address already in use" errors on port 80/443
  • Troubleshooting DNS resolution between Kubernetes pods
  • Testing connectivity between VPCs in cloud environments

The Network Debugging Playbook

Debug Bottom-Up: The OSI Layer Approach

Senior engineers debug network issues by working bottom-up through the OSI model. Start at Layer 3 (IP/Network) and work your way up to Layer 7 (Application).

L3 Network: ping → Is the host reachable?
L3 Routing: traceroute → Where are packets going?
L4 Transport: ss -tuln / nc -zv → Is the port open?
L7 DNS: dig → Does the hostname resolve?
L7 Application: curl -I → Does the API respond?
Logs: grep → What does the application say?

🔍 Diagnostics

Test connectivity layer by layer.

  • ping -c 4 host — ICMP reachability
  • traceroute host — Network path
  • dig hostname — DNS resolution
  • nc -zv host port — Port test
  • curl -I url — HTTP health check

📊 Inspection

Examine local network state.

  • ip addr show — Interface IPs
  • ip route — Routing table
  • ss -tuln — Listening ports
  • cat /etc/resolv.conf — DNS config
  • grep error logfile — Log filtering

Quick Reference: HTTP Status Codes

  • 200 — OK (everything is fine)
  • 301/302 — Redirect (check Location header)
  • 403 — Forbidden (permission/auth issue)
  • 404 — Not Found (wrong URL or endpoint not deployed)
  • 502 — Bad Gateway (upstream server is down)
  • 503 — Service Unavailable (server overloaded)
  • 504 — Gateway Timeout (upstream server too slow)

The Infinity

Weekly tech insights, programming tutorials, and the latest in software development. Join our community of developers and tech enthusiasts.

Connect With Us

Daily.dev

Follow us for the latest tech insights and updates

© 2026 The Infinity. All rights reserved.