← All articles

port forwarding

Port Forwarding for Developers: When to Use It and When Not To

Port forwarding can solve local access problems, but it is often the wrong tool for client review. Compare router, SSH, USB, and tunnel paths.

Published May 3, 2026 5 min read
In this article

Port forwarding means routing traffic from one network location to another port. Developers run into it when a local server works on their machine but needs to be reached by a phone, teammate, webhook provider, or reviewer.

Search results often explain port forwarding through routers and games. Developers need a different map: LAN binding, USB forwarding, SSH forwarding, reverse tunnels, and temporary public links.

Port forwarding for developer workflows

Developers mean one of four things when they say port forwarding:

  • Opening a router port so outside traffic reaches a machine on a private network.
  • Forwarding a local port through SSH to reach a remote service.
  • Forwarding a remote port through SSH so a remote server routes traffic to localhost.
  • Mapping a device port to a dev machine port, such as Android Chrome over USB.

Each path solves a different problem. The wrong one can create more risk than value.

Router port forwarding

Router port forwarding maps an external port on your network to a device and port inside the network. For example, public traffic to port 8080 on your home IP could route to 192.168.1.24:3000.

This can work for a hobby server or a lab environment. It is a poor fit for most local web reviews.

Problems developers hit:

  • You need router admin access.
  • The public IP may change.
  • Some networks use carrier-grade NAT.
  • Corporate and cafe networks block the path.
  • The service stays exposed until someone removes the rule.
  • HTTPS, DNS, and firewall rules become your problem. If you only need a client to review a branch for 30 minutes, router port forwarding gives you too much responsibility.

Local and remote SSH port forwarding

OpenSSH supports TCP forwarding over an encrypted channel. The OpenSSH manual documents -L for local forwarding, -R for remote forwarding, and -D for dynamic SOCKS forwarding.

Local forwarding pulls a remote service to a local port:

ssh -L 5433:localhost:5432 user@example.com

That can make a remote database available at localhost:5433 on your machine.

Remote forwarding pushes a local service to a remote machine:

ssh -R 8080:localhost:3000 user@example.com

That can make your local app reachable from the remote server on port 8080, subject to SSH server settings and bind rules.

SSH forwarding is useful when you control the remote server and understand the network. It is less useful when the reviewer is non-technical and expects a browser link that works from anywhere.

USB port forwarding for mobile debugging

Chrome DevTools supports port forwarding through USB for Android devices. The Android device listens on a local port, and DevTools maps that port back to a server on your development machine.

This is a strong fit for Android Chrome debugging. You can inspect elements, read console output, and test local content on a physical device without changing WiFi or router settings.

It does not help an iPhone user, a remote client, or a webhook provider. It is a device-debugging path, not a public sharing path. For a fuller mobile workflow, see test website on mobile device.

A localhost tunnel gives you the useful part of remote forwarding without requiring your own VPS. Your local machine opens an outbound connection to a relay. The relay gives you a public HTTPS URL. Requests travel back through the outbound tunnel to your local server.

With wiremaven:

npx wiremaven-cli 3000 --expires 30m --name dev-review

This creates a temporary encrypted public link for localhost:3000. It uses an outbound WebSocket, so you do not open inbound router ports. Reviewers get a browser link. During beta, they do not need an account.

wiremaven adds review signals on top of access. You can see viewers join, requests succeed, and failures surface while the session runs. TTL options keep the link scoped to the review window.

Read how wiremaven works for the relay model.

Which forwarding path should you choose?

WorkflowBetter choiceWhy
Reach a remote database from your laptopSSH local forwardKeeps access on your machine
Expose a local app through your own serverSSH remote forwardUses infrastructure you control
Debug Android Chrome over USBChrome port forwardingStrong DevTools integration
Host a long-running home serviceRouter port forwarding or tunnel infraRequires durable operations
Send a client a local review linkwiremavenTime-boxed URL and review visibility
Test a webhook route during a demoTunnel or provider CLIPublic HTTPS and request signals

Security checks before forwarding a port

  • Know which service you are exposing.
  • Bind only the interface you need.
  • Use HTTPS for browser and webhook traffic.
  • Avoid exposing admin routes or debug panels.
  • Add authentication when the session is not invite-only.
  • Set an end time or remove the forwarding rule after use.
  • Watch request logs during the session. The main risk is forgetting that a local development service was never built as a public service. Many dev servers expose stack traces, debug pages, local cookies, and routes that assume a trusted user.

FAQ

Is port forwarding safe for developers?

It can be safe when you scope the service, understand the network, and close the route after use. It becomes risky when a local dev server stays public without authentication or monitoring.

Is SSH port forwarding the same as a tunnel?

SSH port forwarding is one kind of tunnel. Hosted localhost tunnel tools use a similar routing idea but provide a public relay and developer workflow around it.

Do I need router port forwarding to share localhost?

No. A localhost tunnel can create a public URL without router changes because your machine starts an outbound connection to the relay.

What is the best option for client review?

Use a temporary public link with session visibility. The reviewer gets a browser URL, and you can see whether the session worked.

Use the smallest route that fits

For a scoped local review, create a temporary link:

npx wiremaven-cli 3000 --expires 30m --name dev-review

Read the wiremaven docs, then compare this with what is a localhost tunnel, ngrok alternatives, and webhook proxy vs. localhost tunnel.


Related: What Is a Localhost Tunnel? | How to Test Website on Mobile Device