How to fix Local forwarding listen to port failed in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 346 views

SSH local port forwarding fails when the specified local port is already in use by another process. This occurs when establishing tunnels with the -L flag and attempting to bind to a port that another service occupies.

Quick fix

Fixes Local forwarding listen to port failed

lsof -i :8080
ss -tulpn | grep 8080
  1. Check what process is using the port
  2. Kill the conflicting process or choose a different port
  3. Force IPv4 only if dealing with IPv6 conflicts
  4. Verify SSH port forwarding is enabled on the server
ssh — error
lsof -i :8080
ss -tulpn | grep 8080
Local forwarding listen to port failed

What this error means

When you use SSH local port forwarding with the -L flag (e.g., ssh -L 8080:remote.host:80), the SSH client attempts to bind a listening socket to your local machine on the specified port. If that port is already occupied by another process, the bind operation fails and SSH cannot establish the forwarding tunnel. This error typically manifests as 'bind: Address already in use' or 'Could not request local forwarding' in the SSH output.

Typical symptoms

  • SSH command with -L flag exits with 'Could not request local forwarding' or 'Address already in use' error
  • Local port forwarding tunnel is not established even though SSH connection itself succeeds
  • Error message includes the specific port number that failed to bind
  • Connection multiplexing tools (ControlMaster) show mux client forwarding request failures

Common causes

  1. Another process or previous SSH tunnel session is already binding to the specified local port
  2. SSH is attempting to bind to both IPv4 and IPv6 addresses, but one address family is blocked or unavailable
  3. Attempting to use a privileged port (below 1024) without root/sudo permissions
  4. Firewall or security rules blocking the local port binding
  5. SSH server has AllowTcpForwarding disabled in sshd_config

How to fix "Local forwarding listen to port failed"

1Check what process is using the port

Before changing anything, identify what's occupying your desired port.

On Linux/macOS:

bash
lsof -i :8080
ss -tulpn | grep 8080

On Windows:

powershell
netstat -ano | findstr :8080

This shows the process ID (PID) and process name using the port.

2Kill the conflicting process or choose a different port

You have two options:

Option A: Terminate the blocking process (if safe)

bash
kill -9 <PID>  # Replace <PID> with the process ID from step 1

Option B: Use a different local port (recommended)

bash
ssh -L 8081:remote.host:80 user@remote.host

Choose a port number above 1024 (if not using sudo) and above 49151 if possible.

3Force IPv4 only if dealing with IPv6 conflicts

If the error mentions both IPv4 and IPv6 binding attempts, force SSH to use IPv4:

bash
ssh -4 -L 8080:127.0.0.1:80 user@remote.host

The -4 flag tells SSH to use only IPv4 addresses, avoiding dual-stack binding issues.

4Verify SSH port forwarding is enabled on the server

Confirm the SSH server allows TCP forwarding. Connect to the server and check:

bash
grep -i AllowTcpForwarding /etc/ssh/sshd_config

If it shows AllowTcpForwarding no, the server admin needs to change it to yes and restart sshd:

bash
sudo sed -i 's/AllowTcpForwarding no/AllowTcpForwarding yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
5Retry the SSH tunnel with verbose output

After resolving the port conflict, retry with verbose mode to confirm success:

bash
ssh -v -L 8080:remote.host:80 user@remote.host

Look for output like:

bash
Local forwarding listening on 127.0.0.1 port 8080.
Forwarding to remote.host port 80.

This confirms the tunnel is now established.

Advanced notes

Connection Multiplexing Issues: If you use ControlMaster for connection sharing, a stale control socket can cause forwarding requests on subsequent connections to fail. Check ~/.ssh/controlmasters/ for old sockets and remove them: rm ~/.ssh/controlmasters/*.

Privileged Ports: Ports below 1024 (e.g., 80, 443) are reserved and require root/sudo to bind. If your local user isn't root, use a port above 1024 and optionally set up a local firewall rule to redirect traffic: sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080.

TIME_WAIT State: Even after killing a process, the port may remain in TIME_WAIT state for 30-120 seconds. Either wait or use ssh -L 127.0.0.1:8080:... instead of 0.0.0.0:8080 to bind only to localhost.

Remote Service Verification: Ensure the remote service you're forwarding to is actually running and listening. On the remote server: ss -tulpn | grep :80 (replace 80 with your target port).

Frequently asked questions

What does "Local forwarding listen to port failed" mean?
host:80), the SSH client attempts to bind a listening socket to your local machine on the specified port. If that port is already occupied by another process, the bind operation fails and SSH cannot establish the forwarding tunnel. This error typically manifests as 'bind: Address already in use' or 'Could not request local forwarding' in the SSH output.
How do I fix "Local forwarding listen to port failed"?
SSH local port forwarding fails when the specified local port is already in use by another process. This occurs when establishing tunnels with the -L flag and attempting to bind to a port that another service occupies.
What causes "Local forwarding listen to port failed"?
Another process or previous SSH tunnel session is already binding to the specified local port SSH is attempting to bind to both IPv4 and IPv6 addresses, but one address family is blocked or unavailable Attempting to use a privileged port (below 1024) without root/sudo permissions
Is the "Local forwarding listen to port failed" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading