Stop Pinging! Master telnet, nc, curl & nmap for Network Diagnostics + Batch Script

Why ping is not enough

Many developers reflexively run ping when a service is unreachable. ping only proves ICMP is allowed ; it does not guarantee the application port is open. A firewall can block port 3306 while ping succeeds. Conversely, some environments block ICMP entirely, so ping fails even though the business port works. The correct approach: pick the tool based on the protocol and port .

Four core tools at a glance

telnet — Test TCP port reachability; ubiquitous, interactive

nc (netcat) — Test TCP/UDP, send data, scriptable; automation, UDP, batch checks

curl — Test HTTP/HTTPS endpoints; status codes, latency, headers, payloads

nmap — Batch port scanning; scan ranges, discover open ports

TCP port checks: telnet and nc

telnet (simplest)

telnet 192.168.1.100 3306

Connected to … or a blinking cursor on a blank screen → port is reachable.

Connection refused → service not listening or firewall actively rejects (TCP RST).

Unable to connect → network routing issue or silent drop (firewall DROP).

Exit: press Ctrl+], then type quit.

nc (more flexible, script-friendly)

nc -zv 192.168.1.100 3306

Flags: -z scan only (no data), -v verbose.

Success output:

Connection to 192.168.1.100 port 3306 [tcp/mysql] succeeded!

Failure output:

nc: connect to 192.168.1.100 port 3306 (tcp) failed: Connection refused

Batch multiple ports:

nc -zv 192.168.1.100 3306 6379 8080

nmap (scan many ports)

nmap -p 3306 192.168.1.100

open

→ reachable filtered → firewall drop closed → no listener

HTTP/HTTPS: curl is your browser

Basic connectivity

curl -I https://api.example.com/health

-I

fetches headers only. HTTP/1.1 200 OK means the endpoint responds. 4xx/5xx = application error, not network failure.

Measure latency

curl -o /dev/null -s -w '连接时间：%{time_connect}s，总时间：%{time_total}s
' https://api.example.com

Output example: 连接时间：0.032s，总时间：0.187s If connect time > 1 s, suspect network latency or firewall interference.

Add timeout to avoid hanging

curl --connect-timeout 5 -I https://api.example.com

Fails after 5 seconds instead of waiting indefinitely.

Common curl templates

GET : curl "https://api.example.com/users/123" POST form :

curl -d "name=老唐&age=18" "https://api.example.com/user"

POST JSON :

curl -X POST -H "Content-Type: application/json" -d '{"name":"老唐","age":18}' "https://api.example.com/user"

Bearer token :

curl -H "Authorization: Bearer your_token" "https://api.example.com/private"

Save response : curl -o output.json "https://api.example.com/data" Verbose debug : add -v Tip: put complex JSON in a file and use curl -d @data.json.

UDP: nc can try, but prefer protocol-specific clients

nc UDP mode

nc -vzu 192.168.1.100 53

-u

= UDP, -z = scan mode.

Most UDP services don't reply to empty packets; nc only reports "sent", not "service healthy".

Better: use dig for DNS, ntpdate -q for NTP.

nmap UDP scan (slow, comprehensive)

nmap -sU -p 53 192.168.1.100

Warning: UDP scans are slow; avoid large ranges.

Batch IP+port check: one-shot shell script

Script check_connectivity.sh reads targets.txt (format IP:PORT:remark per line), tests each with a 3-second TCP connect via /dev/tcp, then uses nc -zv -w 2 to distinguish refused (service down) from timeout (firewall drop or unreachable IP). Outputs a markdown table: Target|Status|Suggestion.

Script logic (condensed)

timeout 3 bash -c "echo >/dev/tcp/$IP/$PORT" 2>/dev/null
if [[ $? -eq 0 ]]; then STATUS="通"; SUGGEST="正常"
else
  nc -zv -w 2 $IP $PORT 2>&1 | grep -q "refused"
  if [[ $? -eq 0 ]]; then STATUS="不通 (拒绝连接)"; SUGGEST="服务未启动或端口未监听"
  else STATUS="不通 (超时/丢包)"; SUGGEST="防火墙拦截或IP不可达"
  fi
fi

Usage

Create targets.txt:

192.168.1.10:3306:MySQL主库
192.168.1.11:6379:Redis缓存
api.thirdparty.com:443:第三方支付接口

chmod +x check_connectivity.sh && ./check_connectivity.sh targets.txt

Sample output:

目标|状态|建议
MySQL主库 192.168.1.10:3306| 通|正常
Redis缓存 192.168.1.11:6379| 不通 (拒绝连接)|服务未启动或端口未监听
第三方支付接口 api.thirdparty.com:443|不通 (超时/丢包)|防火墙拦截或IP不可达

Case study: Redis timeout traced to cloud security group

Symptom: ping 10.0.0.5 works, but telnet/nc 10.0.0.5 6379 hangs (timeout). Timeout ≠ refused ; timeout means packets are silently dropped mid-path, pointing to a firewall.

On Redis server, trace network syscalls:

sudo strace -f -e trace=network redis-server 2>&1 | grep 6379

No inbound connection attempts from the client IP → packets never reach the process.

Check host firewall: sudo iptables -L -n | grep 6379 Output:

DROP     tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:6379

Root cause: cloud provider security group only allowed internal CIDR; the dev machine was external.

Takeaway : nc 's distinction between "timeout" and "refused" quickly tells you whether the service isn't listening or a firewall is dropping packets.

Quick-reference cheat sheet

TCP port reachable? → telnet IP PORT or nc -zv IP PORT (telnet interactive, nc scriptable)

HTTP/HTTPS health → curl -I URL (check status code)

HTTP latency → curl -o /dev/null -s -w '%{time_total}\n' URL (seconds)

UDP reachable? → nc -vzu IP PORT (unreliable; prefer real client like dig, ntpdate)

Batch port scan → nmap -p 1-1000 IP (use only in owned environments)

Local listening ports → ss -tlnp (faster than netstat)

Path tracing → traceroute IP or mtr IP (identify lossy hop)

Common pitfalls to avoid

telnet fails ≠ network issue — some services whitelist source IPs; a jump host may connect while the app server cannot.

curl 502 ≠ network failure — that's an upstream application error; don't blame the network.

nmap wide scans trigger alarms — cloud providers may flag and ban scanning IPs; restrict to your own VPC.

nc -z unreliable for UDP — many UDP services ignore empty probes; send a real request (e.g., dig for DNS, ntpdate -q for NTP).

Bottom line

Next time someone says "network is down", ask: "Which command did you use?" If they say "browser", send them this guide. Remember:

TCP port → nc -zv HTTP → curl -I (use POST templates for payloads)

UDP → protocol-specific client

Batch checks → the script above