Can you elaborate more on what problem this is solving? I am confused about what this provides that isn't already available with WireGuard.
WireGuard natively supports split tunneling. This same feature is exploited by Tailscale, but is easily configured without needing Tailscale or any other software.
This would seem more useful without WireGuard, but even then, most homelabs already have a gateway or bastion host running SSH, which can already proxy and tunnel connections.
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.
- 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 :)
Can you elaborate more on what problem this is solving? I am confused about what this provides that isn't already available with WireGuard.
WireGuard natively supports split tunneling. This same feature is exploited by Tailscale, but is easily configured without needing Tailscale or any other software.
This would seem more useful without WireGuard, but even then, most homelabs already have a gateway or bastion host running SSH, which can already proxy and tunnel connections.
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 :)