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.