nc — test ports, grab banners, move bytes

$ nc -zvw3 192.168.1.13 8123
nc -zvw3 127.0.0.1 45999

Connection to 192.168.1.13 8123 port [tcp/*] succeeded!
nc: connect to 127.0.0.1 port 45999 (tcp) failed: Connection refused

Real output, both lines, from this box: Home Assistant answers on 8123, nothing answers on 45999. The three flags do one job each — `-z` probes without sending data, `-v` prints the result line at all, `-w3` gives up after three seconds. Exit status is worth knowing: the successful probe returned 0, the refused one returned 1, and a multi-port sweep returns 0 as long as at least one port connected. That is the check to put in front of a deploy script or a monitoring probe: one line, installed everywhere, and no dependency on whether someone left telnet in the image.

$ nc -zvw1 127.0.0.1 6332-6336

nc: connect to 127.0.0.1 port 6332 (tcp) failed: Connection refused
Connection to 127.0.0.1 6333 port [tcp/*] succeeded!
Connection to 127.0.0.1 6334 port [tcp/*] succeeded!
nc: connect to 127.0.0.1 port 6335 (tcp) failed: Connection refused
nc: connect to 127.0.0.1 port 6336 (tcp) failed: Connection refused

Port ranges are a documented but little-known feature — the man page says the port may be given as `nn-mm` — and they map an application's port block in one command: here the qdrant container's two published ports (6333 REST, 6334 gRPC) stand out of five, and the refused lines interleave with the successes as each probe finishes. `-w1` matters because without `-w` the default is no timeout, and one filtered port will make your scan sit there until you kill it. This is not nmap: no SYN scan, no service detection, no concurrency. It is the five-second question 'what is listening in this range', and it needs no install.

$ timeout 4 nc -w3 127.0.0.1 22 < /dev/null

SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.19

A banner grab, verbatim from this machine: connect and wait, and sshd introduces itself before any client has said a word. This is how you find out what is really behind a port when a proxy, a port-forward or a container mapping is in the way — the banner names the software and the exact build. The `< /dev/null` keeps nc from sitting on your keyboard, `-w3` bounds the connect, and `timeout 4` catches the case where the peer accepts the connection and then says nothing forever. Point the same command at 25, 587 or 3306 and you get the SMTP or MySQL greeting instead; a service that greets you in the wrong protocol is the fastest diagnosis you can get.

$ printf 'HEAD / HTTP/1.0\r\nHost: kmail.at\r\n\r\n' | nc -w3 127.0.0.1 3401

HTTP/1.1 200 OK
Vary: rsc, next-router-state-tree, next-router-prefetch, next-router-segment-prefetch, Accept-Encoding
x-nextjs-cache: HIT
x-nextjs-prerender: 1
x-nextjs-prerender: 1
x-nextjs-stale-time: 300
X-Powered-By: Next.js
Cache-Control: s-maxage=31536000
ETag: "12532oag3rp1sox"
Content-Type: text/html; charset=utf-8
Content-Length: 84045
Date: Sun, 11 Oct 2026 07:01:15 GMT
Connection: close

Real headers from the kmail-next container behind this site, fetched with a printf pipe and no client library. Note what only this view gives you: `x-nextjs-cache: HIT` says the page came from the cache, `x-nextjs-stale-time: 300` says how stale it was allowed to be, and `x-nextjs-prerender: 1` is printed twice — that doubling is in the actual response, which is exactly the kind of detail a client hides from you. HEAD gets headers without the body; swap it for GET and pipe into `head -40` when the body is what you want. The blank line before the end is the end of the response, and because this is HTTP/1.0 the server closes the socket rather than keeping it open.

$ # terminal 1 — the receiver
nc -l 127.0.0.1 46001 > received.bin
# terminal 2 — the sender, then the verification
nc -v -w3 -N 127.0.0.1 46001 < payload.bin
ls -l payload.bin received.bin && cmp payload.bin received.bin && echo IDENTICAL

-rw-rw-r-- 1 kmail kmail 300000 Oct 11 09:01 payload.bin
Connection to 127.0.0.1 46001 port [tcp/*] succeeded!
-rw-rw-r-- 1 kmail kmail 300000 Oct 11 09:01 received.bin
IDENTICAL

Ran it end to end: 300000 random bytes, both files exactly 300000 bytes, `cmp` silent and IDENTICAL. No ssh, no keys, no sshd on the far end, no rsync binary, no config — a listener on one machine and a redirection on the other. `-N` is the flag that makes this work in scripts: it shuts down the network socket when stdin hits EOF, so the receiver knows the file is finished. Without it the client keeps the connection open after the last byte and your transfer sits there until something times out. Plaintext on the wire, so treat it as a LAN or tunnel-only tool, and remember the listening socket is open to whoever reaches that port first.

$ # terminal 1 — one listener, many connections
nc -k -l 127.0.0.1 46010
# terminal 2 — two separate sends
printf 'ping-1\n' | nc -w2 -N 127.0.0.1 46010
printf 'ping-2\n' | nc -w2 -N 127.0.0.1 46010

ping-1
ping-2

The listener's terminal shows both arrivals; both client commands exited 0. `-k` requires `-l` and is the difference between a single-shot listener and a small server. I measured the other case on this box: without `-k` the first send still succeeded, the listener process was gone afterwards, and the second send exited 1 with nothing printed — refusals only reach the screen when `-v` is on. So the habit for scripts is `timeout 30 nc -k -l -v 8080` while you are debugging, and never expect nc to restart itself. The same flag pair is how people catch webhooks, and `-F` is how you hand the connected socket off to another program.