Port 8080 HTTP alternate – Free, Online, Private

What listens on 8080

Port 8080 is http-alt. The IANA description is HTTP Alternate (see port 80). The same service name is also registered on 591. 8080 is the one application servers actually use. Tomcat, many proxies, and a pile of admin interfaces bind it and speak HTTP. It is unprivileged, which is why a process that cannot bind 80 binds 8080 and an ingress forwards to it. Port 8008 is http-alt in some older notes and is a different number. Port 8000 is irdmi, not this name. UDP 8080 is in the registry. Browsers use TCP. A request to http://host:8080/ is the test. HTTPS on 8080 is a local choice and will fail a client that expects cleartext.

The IANA service name is http-alt: HTTP Alternate (see port 80). The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 8080. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 8080

Service notes for port 8080: the IANA name is http-alt (HTTP Alternate (see port 80)), and the program people mean is HTTP alternate. TCP 8080 is the IANA http-alt port, HTTP Alternate, with a note to see port 80. Proxies, application servers, and admin UIs listen here. It is not port 591 and not port 8008. Admin consoles ship on 8080. A reverse proxy that is careful about 443 and a security group that allows 8080 from anywhere has published the console. Bind admin listeners to localhost. Do not run an open proxy on 8080. An open forward proxy is an abuse channel, and scanners look for CONNECT. If the port is an application, give it the same authentication you would have given it on 443. The alternate port is not an internal port once a route reaches it. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 8080, you are on the wrong page.

A health check uses 8080 and the app was moved to 8081 by a second instance. Another trap is a proxy that strips Host and breaks an app that generates links. Another is mixed content, a page on 443 calling an API on cleartext 8080, which a browser blocks. Another is a Dockerfile that publishes 8080 while the app reads PORT and listens on 80. The mapping 8080:8080 then refuses. Another is IPv6. A server bound to 0.0.0.0 may not be bound to ::.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 8080 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. The process should be the app or the proxy, on TCP 8080, on the address the upstream uses. curl from the same network as the client is the test. A TCP connect with no HTTP response means something else has the port.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• http-alt on 8080 is the assignment people mean. The name also exists on 591.
• 8000 is irdmi. 8443 is pcsync-https. They are not this port.
• An open proxy on 8080 will be abused.
• UDP 8080 is not how browsers connect.

Linuxsudo ss -lptn 'sport = :8080'
sudo lsof -nP -iTCP:8080 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:8080 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.8080[^0-9]'

Windowsnetstat -ano | findstr :8080
Get-NetTCPConnection -LocalPort 8080

Remotenc -vz host 8080