- 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 :)
- This seems useful if users don't have admin access to override local DNS/hosts, but I'm not the only one still confused why it's necessary for those who do.
If I'm vanilla SSH forwarding 127.0.0.1:12345 to the target, and override the .tld FQDN locally to resolve to 127.0.0.1, it will not work? Maybe you could document a bit more about the error(s) you ran into doing this so I can catch up with your understanding.
Otherwise the sales pitch is less hassle, which makes sense but it's always helpful to document alternatives so that everyone is in the same page.
- [dead]
- Wow, SEO for the top comment in HN... a sad day. Maybe only because it was a small Show HN but it's definitely worth keeping track of which accounts upvoted this.
- [dead]
5 points by Madh93 7 months ago | 6 comments