burp proxy listener failed to bind: address already in use on tester machine

TL;DR

Something already owns the port Burp wants, commonly a previous Burp instance that never closed, another proxy, or a leftover Java process. Identify the owner with a socket listing, close or move it, or put the Burp listener on a different loopback port and update the browser to match, keeping the pair consistent.

burp proxy listener failed to bind: address already in use on tester machine

Use this when

• Burp shows the listener as failed or inactive with an address already in use error.
• Burp was restarted after a crash, or another intercepting proxy runs on the same tester box.

Not for this skill when

• Burp listens fine but the browser cannot reach the internet through it. That is an upstream proxy or certificate problem.
• The port owner is a client VPN agent you must not kill. Move Burp instead.

Steps

1. Note the exact address and port Burp tried to bind from the listener settings and the error text. Verify: Verify: you have the port number the conflict is about, usually the default loopback proxy port.
2. List what owns it, using ss or netstat with process display, and identify the program by name. Verify: Verify: the owner is named, most often a stale Burp or Java process from an earlier session.
3. If it is your own stale process, close that application properly and confirm the port is free; if it is something needed, leave it alone. Verify: Verify: the socket listing no longer shows a listener on that port, or you have decided to move Burp.
4. Either restart the Burp listener on the freed port, or edit the listener to a free loopback port and change the browser proxy setting to the identical value. Verify: Verify: Burp marks the listener running and the browser loads a page through it.
5. Load an HTTP page on an authorized test site and confirm traffic appears in the proxy history. Verify: Verify: the intercepted request shows in Burp, proving the whole chain, not just the bind.

Variant phrasings

burp port 8080 already in use another process

The default-port phrasing.

burp listener inactive after crash restart

The stale-process phrasing.

change burp proxy listener port browser mismatch

The move-the-listener phrasing.

Compatibility: Compatibility: Burp Suite Professional and Community on Windows, macOS, and Linux; socket listing commands differ by OS.

Why it happens

A TCP port on one address can have exactly one listener. Burp does not steal ports, so a surviving process from a crashed session, a second Burp instance, or an unrelated tool on the same default port blocks the bind. The error is reported by the operating system, which is why Burp itself cannot tell you what the other process is.

Edge cases / pitfalls

• Two Burp instances can both run if their listeners differ; label projects so you know which instance holds which port.
• Freeing the port by killing an unknown process can break the client VPN or endpoint agent on a managed box; identify first, always.
• After moving ports, saved browser profiles and mobile device proxy settings still point at the old one; update every client you use.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5feyux5byJD0ji9HTRvDg