Port 1080 SOCKS – Free, Online, Private

What listens on 1080

Port 1080 is SOCKS. The IANA name is socks, on TCP and UDP. The proxy administrators run is a TCP listener. The client connects, offers a version, authenticates if required, and then asks the proxy to connect to some other host, or to associate a UDP relay. The UDP relay is a separate socket chosen at runtime. It is not 'the service is UDP 1080'. A program that says it uses a SOCKS proxy and is pointed at 8080 is pointed at an HTTP proxy, which is a different protocol. SSH dynamic forwarding, ssh -D, speaks SOCKS and often listens on 1080 on localhost.

The IANA service name is socks: Socks. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 1080. 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 1080

Service notes for port 1080: the IANA name is socks (Socks), and the program people mean is SOCKS. TCP 1080 is the IANA socks port. A SOCKS5 proxy accepts a TCP control connection here. UDP associate is negotiated inside that connection. An open SOCKS proxy is an open relay for TCP. Scanners look for exactly that. Require authentication, or bind to localhost and reach it through SSH. Do not publish 1080 on a public address. A proxy that allows connections to 169.254.169.254 or to RFC1918 addresses will be used to poke cloud metadata and internal services. Block those destinations. Logging the target host is how you notice abuse. The proxy sees the destination name or address. That is the privacy trade. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 1080, you are on the wrong page.

A browser set to use SOCKS on 1080 while nothing is listening fails closed, which looks like the internet is down. A browser set to use an HTTP proxy on 1080 sends an HTTP request to a SOCKS server and gets a confused error. Match the proxy type. Another trap is testing with nc -vz and treating success as a working proxy. The handshake has not happened. Another is Docker publishing 1080 for a local tool and forgetting the publish is on all interfaces. ss shows 0.0.0.0 when that happens.

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 1080 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. A localhost bind is what you want for an SSH dynamic forward. A public bind needs a reason and authentication. From outside, the port should not accept a handshake unless you meant it to.

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 proxies are often 8080 or 3128. SOCKS is 1080. The protocols are not interchangeable.
• UDP associate does not mean the well-known listener is UDP.
• An open 1080 is a relay. Treat it like one.
• nc proving TCP accept does not prove the proxy will connect onward.

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

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

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

Remotenc -vz host 1080