Vast.ai Port Not Listening: A Step-by-Step Diagnosis

A "port not listening" error is the most common reason a Vast.ai machine fails verification or drops out of search results. The bad news: the failure can live in any of four places between your service and the renter. The good news: if you test those four places in order, from the machine outward, you find the broken link in minutes instead of hours of guessing.

The four places a port can die

When Vast.ai says a port is not listening, it means its external probe could not complete a TCP connection. That connection has to survive four hops, and each one can silently kill it:

The service itself. Nothing is bound to the port on the machine, so there is nothing to connect to.
The local firewall. The service is listening, but ufw or iptables drops the packet before it arrives.
The router or NAT. The machine is fine, but your router never forwards the port range from your public IP to the host's LAN address.
The outside world. Everything on your side works, but your ISP blocks the range, or the marketplace probe tested before your changes took effect.

Always test in that order. If you start from the outside, a single failed check tells you nothing about which of the four layers ate the packet.

Step 1: Is anything listening on the machine

SSH into the host (or use the console) and check what is actually bound:

ss -tlnp

Look for your assigned port range in the Local Address column. A line like 0.0.0.0:40000 means the service accepts connections from any interface. A line like 127.0.0.1:40000 means it only listens on localhost and no external probe will ever reach it. No line at all means the service is not running: check it with systemctl status or docker ps before you touch anything network-related.

A known Ubuntu quirk: missing /run/sshd

On some Ubuntu setups sshd refuses to start because the /run/sshd privilege separation directory is missing after a reboot. The fix is quick:

sudo mkdir -p /run/sshd && sudo chmod 0755 /run/sshd

Because /run is a tmpfs and empties on every boot, persist the fix with a tmpfiles.d entry. Create /etc/tmpfiles.d/sshd.conf containing the single line d /run/sshd 0755 root root - and systemd will recreate the directory at every boot from then on.

Step 2: Is the local firewall open

Confirm the firewall is not eating the traffic:

sudo ufw status

If ufw is active, you need an explicit allow rule for your Vast.ai port range, for example sudo ufw allow 40000:40100/tcp. If the status shows inactive, the firewall is not your problem; move on. While you are on the machine, prove the port answers locally with curl -v telnet://127.0.0.1:40000 or nc -zv 127.0.0.1 40000. A local success plus an external failure narrows the fault to the router or beyond.

Step 3: Does the router forward the range

Vast.ai assigns each machine a block of ports, and every one of them must be forwarded from your router to the host's LAN address. Two mistakes cover most cases here:

Forwarding single ports instead of the range. The machine needs the whole block. Forward the full range shown on your host dashboard, not just the one port that failed.
The host changed LAN address. A DHCP lease renewal after a reboot can hand the machine a new address, and the forwarding rule now points at nothing. Give the host a static LAN address or a DHCP reservation.

The full router-side setup, including static addressing, is covered in our guide on port forwarding and NAT for GPU hosts.

Step 4: Test from outside your network

A test from inside your LAN can lie to you: many routers cannot hairpin traffic to their own public IP. Test from a genuinely external vantage point, such as a phone on mobile data, a cheap VPS, or a friend's connection:

nmap -Pn -p 40000-40100 YOUR_PUBLIC_IP

Ports reported as open are reachable. filtered means something dropped the packet silently (firewall, NAT, or ISP), and closed means the packet arrived but nothing was listening, which points you back to step 1. For a deeper walkthrough of external testing, see the port check guide and the nmap CLI reference in our open source Linux tools collection.

When every check passes and Vast.ai still complains

If the service listens, the firewall allows it, the range is forwarded, and an external nmap shows the ports open, but the marketplace still reports a port error, you are probably looking at a stale status on the marketplace side rather than a real network fault. This happens more often than you would expect, and the diagnosis is different: you need to prove your side works and then compare what your dashboard says against the public listing.

One more Ubuntu-specific trap worth knowing: on 22.04 a netplan misconfiguration can leave the machine with a link but no usable route after an upgrade, which looks exactly like a port problem from the outside. The 22.04 netplan issue writeup covers that case.

For the stale-status scenario, including how to compare the private and public verification views and when to involve Vast support, continue with our guide on deverified machines and sync issues. And if the machine has dropped off the marketplace entirely, start from the top with the 10-minute offline checklist.