llama.cpp connection refused after update? the port moved

llama.cpp v0.7.0 (released 2026-10-15) changed llama-server's default port from 8080 to 9931. Add --port 8080 to your start command to restore the old binding, or update your scripts to 9931 — and pin the flag either way, because a default port is an API.

Defaults are APIs. When one moves, your scripts are the error message:

$ curl -sv http://127.0.0.1:8080/health
*   Trying 127.0.0.1:8080...
* connect to 127.0.0.1 port 8080 from 127.0.0.1 port 60306 failed: Connection refused
* Failed to connect to 127.0.0.1:8080 after 1 ms: Could not connect to server
* closing connection #0

That is the whole bug. Upstream shipped a faster MoE cache, speculative decoding, a models manager — and quietly renumbered the front door. The release notes list it in one clause: "a new default port (9931)". Every tutorial, systemd unit, cron job and bookmark that says 8080 stopped working on upgrade day. I booted the 0.7.0 build on a clean box to catch the exact receipts; they're below.

What port does llama-server use now?

9931. The binary names its build, the boot log names the door:

$ ./llama-server --version
version: 0.7.0-dev (build 11669, commit 620d2225c)
built with GNU 11.4.0 for Linux x86_64

$ LD_LIBRARY_PATH=. ./llama-server -m /root/t.gguf
…
0.00.041.420 I srv  llama_server: model loaded
0.00.041.442 I srv  llama_server: listening on http://127.0.0.1:9931

Listening about 41 ms after process start (test-size model, one vCPU); the port line is on the record. Ask the new door for health:

$ curl -s http://127.0.0.1:9931/health
{"status":"ok"}

Why is llama.cpp connection refused after the update?

Most likely first: four causes cover nearly every refusal after an upgrade:

1. The silent renumber. v0.7.0 binds 9931 unless you say otherwise. Your client still knocks on 8080, where nothing answers. That is the refusal in the opening: 1 ms means nobody is home on that port, not a slow server.
2. The server died before it was ready. Searches for "llama.cpp server exited before becoming ready" are their own genre. Upgrades move flags; a bad -m path or a renamed argument kills the process during startup, and every later curl refuses. Read the boot log first — the bind line prints the port, the fatal line prints the reason.
3. Wrong interface. The server binds 127.0.0.1 by default. Curling from another machine? Refused, even on the right port. That one needs --host 0.0.0.0 — and a thought about who can now reach your model.
4. A stale llama-server is squatting the socket. The old binary from before the upgrade is still running, holding 8080 in a broken state — or your new boot failed with "address already in use" and you only saw the curl error. ss -tlnp settles it.

Every refusal, one table

How do I get 8080 back?

One flag:

./llama-server -m ./model.gguf --port 8080

verify: curl -s http://127.0.0.1:8080/health → {"status":"ok"} — the boot log now reads listening on http://127.0.0.1:8080.

Under systemd, pin it in the unit so nothing depends on upstream mood:

[Service]
ExecStart=/opt/llama.cpp/llama-server -m /models/model.gguf --port 8080 --host 127.0.0.1

verify: systemctl cat llama-server | grep ExecStart shows the flag · restart, then the health curl above answers.

How do I stop the next update from breaking me?

The renumber is not a llama.cpp flaw — defaults move, and 8080 is a crowded neighbourhood anyway. The flaw is trusting one. Make the port explicit everywhere and this class of outage dies:

• Pin --port in every unit, script and compose file — never rely on a default you don't own.
• Audit today: grep -rn "8080" ~/.config/systemd ~/scripts 2>/dev/null — every hit is a future outage.
• Read Highlights for the word "default" before any upgrade — that word is where breaking changes go to hide.
• Keep the boot log — the bind line names the port before anything can drift.

$ /bin/ss -tlnp | grep -E '8080|9931'   # default boot
LISTEN 0      0          127.0.0.1:9931      0.0.0.0:*    users:(("llama-server",pid=190,fd=3))

$ /bin/ss -tlnp | grep -E '8080|9931'   # after --port 8080
LISTEN 0      0          127.0.0.1:8080      0.0.0.0:*    users:(("llama-server",pid=105,fd=3))

Last tested 2026-10-20 on a clean 1-vCPU / 1 GiB jbench microVM. Binary: the prebuilt b11669 — the commit that bumped the version to 0.7.0 (its own banner says 0.7.0-dev; the release tag itself ships no binaries). Receipts pasted as-is; the box fought back (no curl, no libgomp) and the receipts survived.

The same release that moved this port also refactored the chat session API. Somewhere in a Highlights list near you, the next breaking change is already dressed as good news. Which default are you still trusting?