Networking Essentials for Cloud and Web Hosting: What You Use Daily

The path of a web request (the map you troubleshoot with)

Most “website not loading” and “SSH times out” tickets become easy when you trace the same path every time: client → internet → edge → VPC/VNet → instance/container → application. Each segment has a small set of networking concepts you use daily. When something breaks, you’re usually missing one of: correct addressing, correct routing, or allowed traffic (policy).

• Client: your laptop, a user’s phone, a monitoring node.
• Internet: public routing between networks.
• Edge: DNS, CDN, load balancer, reverse proxy, WAF, NAT gateways—anything that fronts your service.
• VPC/VNet: your private cloud network: subnets, route tables, NACLs, security groups.
• Instance/container: VM NICs, container interfaces, host firewall, listening services.
• Application: HTTP server/app framework, TLS configuration, upstream dependencies.

Key terms you will use constantly (and what they mean in hosting)

IP address

An IP address is a Layer 3 identifier used to route traffic to a host or service. In hosting you’ll deal with:

• Public IP: reachable from the internet (often attached to a load balancer, NAT, or instance).
• Private IP: reachable only inside your VPC/VNet or via VPN/peering.

Hosting example: “Website not loading” — DNS resolves to an IP, but the IP is wrong (old load balancer, wrong environment) or the service moved and the IP changed.

Subnet

A subnet is a range of IP addresses within a VPC/VNet. Subnets usually map to a zone/segment and determine which route table and network policies apply.

Hosting example: “SSH times out” — the instance is in a private subnet with no inbound path from the internet (no bastion, no VPN, no public IP), so SSH from your laptop can’t reach it.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Default gateway

The default gateway is where a host sends traffic destined for outside its local subnet. In cloud, the “gateway” is typically the VPC router (implicit) and the route table decides whether traffic goes to an internet gateway, NAT gateway, VPN, peering, etc.

Hosting example: “Outbound updates fail” — the instance can’t reach package repositories because its subnet routes don’t send 0.0.0.0/0 to a NAT gateway (private subnet) or internet gateway (public subnet).

MAC address

A MAC address is a Layer 2 identifier used on a local network segment. In cloud you rarely troubleshoot raw switching, but MAC concepts still matter when you see ARP/neighbor issues, duplicate IPs, or container networking quirks on a host.

Hosting example: “Intermittent connectivity inside the same subnet” — a misconfigured virtual appliance or container bridge can cause ARP confusion; symptoms look like random timeouts to a private IP.

Port

A port is a Layer 4 number that identifies a service on a host (TCP/UDP). Common ports in hosting: 80/443 (HTTP/HTTPS), 22 (SSH), 53 (DNS), 3306 (MySQL), 5432 (PostgreSQL).

Hosting example: “Site loads on HTTP but not HTTPS” — port 80 is open and forwarded correctly, but port 443 is blocked by a security group, NACL, host firewall, or the app isn’t listening on 443.

Protocol

A protocol defines how data is transported and interpreted. Daily hosting work focuses on:

• TCP: connection-oriented; most web and SSH traffic.
• UDP: connectionless; DNS, some monitoring, some VPNs.
• ICMP: ping/traceroute style diagnostics (often blocked at edges).
• HTTP/HTTPS: application-layer web traffic (often behind TLS).

Hosting example: “Ping fails but website works” — ICMP may be blocked while TCP/443 is allowed; ping is not proof that the web service is down.

Route

A route tells a router where to send traffic for a destination prefix. In cloud, you’ll constantly check subnet route tables and next hops (internet gateway, NAT gateway, transit gateway, peering, virtual appliance).

Hosting example: “Users can reach the load balancer but backend health checks fail” — the backend subnet route table may be missing a return route to the load balancer’s source range or to a peered network.

Firewall / Security group (and related policy controls)

“Firewall” is the general concept: rules that allow/deny traffic. In cloud you typically have multiple layers:

• Security group: stateful allow rules attached to instances/ENIs or load balancers.
• NACL: stateless rules applied at the subnet boundary (both inbound and outbound must be allowed).
• Host firewall: iptables/nftables/ufw/Windows Firewall on the instance.
• WAF: application-aware filtering at the edge.

Hosting example: “SSH times out” — security group allows TCP/22 from your IP, but the NACL blocks ephemeral return ports, or the host firewall blocks 22, or SSH is listening only on a private interface.

Follow the request path: what to check at each hop

1) Client → Internet: name resolution and basic reachability

Before you blame the server, confirm the client is actually targeting the right destination and using the right protocol.

• DNS: does the hostname resolve to the expected IP(s)?
• Correct scheme/port: https:// vs http://, and any non-standard ports.
• Local network constraints: corporate proxy, captive portal, local firewall.

Step-by-step: verify DNS and target

# Resolve the hostname (compare results from different resolvers if needed)  dig +short example.com  nslookup example.com  # Confirm the IP is what you expect (e.g., load balancer public IP)  # Then test TCP connectivity to the service port  curl -I https://example.com  curl -Iv https://example.com:443  # If SSH:  ssh -vvv user@example.com

2) Internet → Edge: CDN/load balancer/WAF behavior

The edge is where many “it works for me” issues live: caching, TLS termination, redirects, and policy blocks.

• CDN: cached errors, stale content, geo-based routing.
• Load balancer: listener ports, target group health, TLS certificates, SNI.
• WAF: blocks based on IP reputation, request patterns, missing headers.

Hosting example: “Website not loading for some users” — the edge may be returning 403/429 due to WAF rules or rate limiting, while origin servers are fine.

Step-by-step: isolate edge vs origin

# 1) Inspect response headers/status to see who answered (CDN vs origin)  curl -I https://example.com  # 2) If you can, hit the origin directly (private test path, or temporary host entry)  # Example: curl to load balancer DNS name or origin IP (only if allowed)  curl -I http://ORIGIN_IP:80  # 3) Check TLS handshake details (cert/SNI mismatch often shows here)  openssl s_client -connect example.com:443 -servername example.com

3) Edge → VPC/VNet: public entry and routing into private networks

Once traffic reaches your cloud boundary, it must be routed to the right subnet and allowed by network policy.

• Public entry: internet gateway + public subnet, or managed load balancer with public listeners.
• Private backends: load balancer forwards to private IPs in private subnets.
• Routes: ensure subnets have correct next hops for inbound/outbound paths.

Hosting example: “Load balancer is up, but targets are unhealthy” — security group on instances doesn’t allow the load balancer’s source security group, or NACL blocks health check ports, or the instance has no route back.

4) Subnet policy: security groups vs NACLs (stateful vs stateless)

This is a frequent source of confusion:

• Security groups are stateful: if inbound is allowed, return traffic is automatically allowed.
• NACLs are stateless: you must allow both inbound and outbound explicitly, including ephemeral ports for return traffic.

Practical mapping: “SSH times out”

• Security group allows TCP/22 from your IP → good.
• NACL inbound allows TCP/22 → good.
• NACL outbound must allow ephemeral ports (client-side) for return traffic → if blocked, SSH can hang/time out.

5) Instance/container: NIC, host firewall, and listening service

Even with perfect cloud routing and policy, the host must accept the connection.

• Correct IP binding: service listening on 0.0.0.0 vs only 127.0.0.1 or only a private interface.
• Host firewall: iptables/nftables/ufw rules may block ports.
• Service health: process down, crashed, or overloaded.
• Container networking: port mapping (hostPort/containerPort), service mesh sidecars, node security rules.

Step-by-step: verify the service is actually listening

# On the instance (Linux examples)  # 1) Confirm IP addressing  ip addr  ip route  # 2) Confirm the port is listening  ss -lntp | grep -E ':80|:443|:22'  # 3) Test locally (bypasses external routing/policy)  curl -I http://127.0.0.1:80  curl -I http://PRIVATE_IP:80  # 4) Check host firewall quickly (tooling varies)  sudo iptables -S  sudo nft list ruleset

6) Application: HTTP/TLS behavior and upstream dependencies

If you can connect to the port but the site still fails, you’re often in application territory:

• HTTP status codes: 301/302 redirect loops, 401/403 auth, 404 routing, 500 app errors.
• TLS: wrong certificate, expired cert, missing intermediate, SNI mismatch.
• Upstreams: app can’t reach database/cache/API due to routes or security rules (looks like “site down” but is actually backend connectivity).

Hosting example: “Homepage returns 502/504” — edge can reach the load balancer, but the app can’t reach its upstream or is timing out; check internal routes and security groups between app and database.

Term-to-symptom cheat sheet (what to suspect first)

• IP address: wrong destination, moved service, wrong environment; symptom: consistent failure for everyone.
• Subnet: private vs public placement; symptom: works only from inside VPN/VPC, not from internet.
• Default gateway: missing outbound path; symptom: instance can’t reach updates/APIs, health checks fail due to no return path.
• MAC address (L2): rare in cloud, but shows as weird intermittent local-subnet issues; symptom: sporadic timeouts to a neighbor IP.
• Port: wrong listener or blocked port; symptom: HTTP works but HTTPS fails, or SSH fails while ping works.
• Protocol: ICMP blocked, UDP vs TCP mismatch; symptom: traceroute/ping misleading, DNS issues when UDP/53 blocked.
• Route: missing/incorrect next hop; symptom: one-way connectivity, can connect from A→B but not B→A, or only some networks can reach.
• Firewall/security group/NACL: policy denies; symptom: timeouts (not refusals), or works from one source IP but not another.

Checklist mental model: diagnose connectivity fast

1) Identify scope: local vs remote

• Local test: from the instance/container itself (curl localhost, check listening ports). If local fails, it’s not a network path problem yet.
• Same VPC/VNet test: from a peer instance in the same network segment. If this works but internet fails, focus on edge/public entry and policy.
• Remote test: from your laptop or an external probe. If only remote fails, focus on DNS, edge, public routing, and inbound rules.

2) Identify the layer: L2 vs L3 vs L4

• L2 (MAC/ARP): mostly inside a subnet; suspect when same-subnet traffic is flaky.
• L3 (IP/routing): can’t reach a subnet/network; traceroute patterns, missing routes, wrong gateways.
• L4 (TCP/UDP ports): IP reachable but specific service fails; SYN timeouts vs connection refused.

3) Verify addressing (before changing rules)

• Confirm DNS resolves to the intended IP/load balancer.
• Confirm the instance has the expected private IP and is in the expected subnet.
• Confirm the service is listening on the expected port and interface (0.0.0.0 vs localhost).
• Confirm return path: instance route table/default route is correct for where replies must go.

4) Verify policy in order (outside-in and inside-out)

• Edge policy: WAF rules, CDN restrictions, load balancer listeners and target health.
• Security groups: allow the right source (your IP, load balancer SG, VPC CIDR) to the right destination port.
• NACLs: allow inbound and outbound, including ephemeral ports for return traffic.
• Host firewall: allow the port on the OS.
• App policy: app-level allowlists, auth, TLS requirements.