Testing from Outside

Testing from Outside with curl, dig and traceroute

A test on the server proves only that the service answers over loopback, and loopback bypasses every firewall rule you are about to write. Test twice: on the server, and from another network such as your laptop or a phone hotspot. curl 3,008 -I sends a HEAD request and prints the response headers:

Asking Apache for its headersShell

curl -I http://localhost

Output

HTTP/1.1 200 OK
Date: Wed, 23 Sep 2026 05:28:30 GMT
Server: Apache/2.4.66 (Ubuntu)
...
Content-Type: text/html

-w '%{http_code} %{remote_ip}\n' prints the status and the address actually used. --resolve www.example.com:80:203.0.113.10 sends the request to a chosen IP while keeping the real host name, so you can test a new server's virtual host before DNS points at it, and -v shows the TLS handshake and every header. For a port that does not speak HTTP, nc -zv host 3306 reports whether TCP connects.

dig (package bind9-dnsutils) queries DNS directly, bypassing /etc/hosts and local caches. After changing a record, dig @1.1.1.1 +noall +answer example.com asks a public resolver; here it printed two A records with a TTL of 29, the seconds a resolver may keep serving the old answer. dig +short prints only addresses.

traceroute lists the routers on the path by sending probes with rising TTLs. The default UDP probes are often dropped, so sudo traceroute -T -p 443 -n example.com sends TCP SYNs to the port you care about. Run here, it showed the Windows host that runs WSL 6 as hop 1, stars for hops 3 to 12 (routers that do not answer probes, which is normal), and example.com replying on port 443 at hop 13. If a TCP trace to your server dies only at the last hop, the packets reach its network and are dropped there: a firewall, not routing.

MENU