Proxer

You have a service on a private machine and you need a stable URL for it. Maybe it is a dev server on a laptop, a dashboard on a homelab box, or an internal tool in a small office. You do not want to open inbound ports to that network just to make one HTTP app reachable.

Proxer gives you the tunnel shape without outsourcing the public endpoint. Run one public Proxer server, then start clients from the private side. Each client dials out over WebSocket, registers a host route, and forwards public HTTP, Server-Sent Events, and WebSocket traffic to 127.0.0.1:<port> on that client machine.

What it is good at

• A stable public URL for a private HTTP service.
• Client-initiated tunnels from NATed or firewalled networks.
• One listener for public HTTP traffic, WebSocket upgrades, health probes, and tunnel control.
• Explicit routing by host with auto-assigned, chosen subdomain, or root-domain routes.
• Deployments where you already run a VPS, reverse proxy, or small edge box.

Routing is not guessed

With --domain proxy.example.com, a client without --subdomain gets a random subdomain such as px-k7m3q9t2ab.proxy.example.com. A client with --subdomain demo handles demo.proxy.example.com. A client with --subdomain @ handles the root host proxy.example.com.

If the incoming host does not match a registered route, Proxer returns 404. It does not send traffic to the only connected client just because there is one. That is less magical, but much safer when a few tunnels are sharing the same server.

First command shape

proxer server --listen 0.0.0.0:8080 --domain your-server.example.com --token dev-token

proxer http 3000 \
  --server wss://your-server.example.com \
  --subdomain demo \
  --token dev-token

curl https://demo.your-server.example.com/

For real deployments, replace dev-token with a long random token supplied through PROXER_TOKEN or your platform’s secret store.

Start with Getting Started if you want the full local-to-public walkthrough.