Show HN: I built a tool to use my homelab apps remotely without a full VPN
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.
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.
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 :)