For multi-hop tunnels write a numbered curl-test command
Encapsulating a multi-machine pipeline (Mac whisper-server → SSH tunnel → socat relay → Docker container) as a reusable setup script
When you write a setup script that wires multiple network hops together, include an explicit test subcommand that issues a single curl against each hop in order and prints the result as a numbered layer. Like: Layer 1 — Mac whisper-server direct, Layer 2 — VM hitting tunnel endpoint, Layer 3 — VM hitting relay endpoint, Layer 4 — container hitting relay. When something breaks, the LAYER NUMBER tells you exactly which component is at fault. Without this pattern, every debug session starts from scratch — was it the tunnel, the firewall, the relay binding, or the container network? With a numbered test command, you bisect a 4-component pipeline in under 5 seconds. Plus: it doubles as a smoke check after start, so the user can run start then test and confirm everything is healthy before kicking off the actual workload. Same idea applies for any setup that wires N components in sequence (sidecars, proxies, service mesh, multi-stage data pipelines). Cost: ~20 lines of bash for the test subcommand. Payoff: every future debug session for this pipeline is 10x faster.
When writing any multi-hop pipeline setup script, build a test subcommand alongside start. Each test should be a single curl with -m 3 (or equivalent for the protocol), wrapped in an echo Layer N — <description> so the output is self-explanatory. Make it the first thing the user runs after start and the first thing they reach for when something breaks.