The specific problem prxy solves is not at the network level, but at the application level, especially for tools that don't have built-in proxy settings.

With WireGuard's AllowedIPs, you route all traffic for a certain IP range through the tunnel. My use case was different: I wanted a specific browser extension to connect to my homelab, while my main browser traffic to the public internet remained on my local network. The extension only has a field for a URL, not for proxy settings.

While an SSH tunnel can achieve a similar result, I find prxy more convenient for this specific workflow because:

- It automatically rewrites the Host header, which is crucial when your homelab service sits behind a reverse proxy (like Traefik or Nginx). - It's a simple, declarative command designed for this one purpose, making it easy to script or use in a container.

So, in short: prxy is a user-space tool for application-specific tunneling when the app itself is not proxy-aware.

So you could achieve the same by using the hosts file ?

Combining hosts file doesn't quite work:

- hosts + WireGuard AllowedIPs: This gives you a network-level tunnel. All applications on your system are forced through the VPN for that IP. You lose the per-app control.

- hosts + SSH Tunnel: This still doesn't fix the Host header problem. My remote reverse proxy gets a request for Host: localhost and returns a 404.

prxy solves both issues. It's an application-level proxy that correctly rewrites the Host header on the fly. It gives you the granular control that other methods lack. It’s a solution for a very specific problem, and other options are perfectly valid if you don't have the same constraints I did of course :)