Show HN: I built a tool to use my homelab apps remotely without a full VPN(github.com)
github.com
Show HN: I built a tool to use my homelab apps remotely without a full VPN
https://github.com/Madh93/prxy
8 comments
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.
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.
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 :)
- 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.
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.
monicaaa(1)
The idea was born out of my frustration with accessing my self-hosted services when I'm on the go. I use WireGuard to connect to my homelab, but I really dislike sending all my computer's traffic through my home network — it slows things down and is inconvenient.
I wanted proper application-level split-tunneling. A tool I love, wireproxy, got me most of the way there by creating an HTTP proxy from a WireGuard peer. This is perfect for apps that let you configure a proxy.
The problem was the other 10%: apps that don't. Think of browser extensions or simple clients that just have a single URL field.
That's why I created prxy. It's a dead-simple local reverse proxy that forwards traffic to another outbound proxy (like wireproxy). The key feature is that it automatically rewrites the Host header, so the request reaches the correct backend service in my homelab, even behind another reverse proxy.
For example, to get a browser extension working with my self-hosted Karakeep instance, I just run:
``` prxy --target https://karakeep.my-homelab.tld \ --proxy http://127.0.0.1:25345 \ --port 12345 ```
By setting the extension's URL to http://localhost:12345, it just works as if I were on my local network.
Hopefully, this can be useful to others in the community.