970cb446daabf7f4ed3a0357e4530958d3aa2f34
release / release (push) Successful in 5m1s
Builds static linux/amd64 binary on v* tags and uploads a tarball containing the binary + lxc/ scripts + npm/ config so deploys can work from a single artifact.
weircon-random-proxy
En public-facing fetch-API der henter en URL gennem en tilfældig (eller klient-valgt) Proton WireGuard tunnel og returnerer svaret. Erstatter den lokale nh-scrape/proxy-stack/ Docker-stak med en LXC på Proxmox.
Arkitektur
Internet
│
▼
┌──────────────────────────────────┐
│ NginxProxyManager (eksisterende)│
│ • TLS termination │
│ • Tjekker X-WEIRCON-RANDOM-IP │
│ (API key) i header │
│ • Stripper headeren før proxy │
└──────────────┬───────────────────┘
│ http://<lxc-ip>:8080
▼
┌──────────────────────────────────────────────────────┐
│ LXC: weircon-random-proxy (unprivileged + TUN) │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ fetch-service (Go, net/http+ReverseProxy :8080)│ │
│ │ • Læser mål-URL fra: │ │
│ │ - query: ?url=https://example.com │ │
│ │ - header: X-WEIRCON-RANDOM-IP-REDIRECT │ │
│ │ • Læser proxy-valg fra: │ │
│ │ - header: X-WEIRCON-PROXY-ID (0-9) │ │
│ │ - default: tilfældig │ │
│ │ • SOCKS5 via 10.99.0.{10+id}:1080 │ │
│ │ • Streamer response chunked tilbage │ │
│ └─────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌──────┴──────┐ br-weircon (10.99.0.1/24)│
│ │ bridge │ │
│ └──┬───┬───┬──┘ │
│ veth ────┘ │ └──── veth │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ netns: │ │ netns: │ │ netns: │ …× 10 │
│ │ proxy0 │ │ proxy1 │ │ proxy9 │ │
│ │ veth: │ │ veth: │ │ veth: │ │
│ │10.99.0.10│ │10.99.0.11│ │10.99.0.19│ │
│ │ + wg0 │ │ + wg0 │ │ + wg0 │ │
│ │ + micro │ │ + micro │ │ + micro │ │
│ │ socks │ │ socks │ │ socks │ │
│ │ :1080 │ │ :1080 │ │ :1080 │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ ▼ ▼ ▼ │
│ Proton Proton Proton (via wg0) │
└──────────────────────────────────────────────────────┘
Klient-API
Eksempel — hent en URL gennem en tilfældig tunnel:
curl -H "X-WEIRCON-RANDOM-IP: $API_KEY" \
-H "X-WEIRCON-RANDOM-IP-REDIRECT: https://api.ipify.org" \
https://random-proxy.weircon.dk/
Eller via query param:
curl -H "X-WEIRCON-RANDOM-IP: $API_KEY" \
"https://random-proxy.weircon.dk/?url=https://api.ipify.org"
Pin en specifik tunnel:
curl -H "X-WEIRCON-RANDOM-IP: $API_KEY" \
-H "X-WEIRCON-PROXY-ID: 3" \
"https://random-proxy.weircon.dk/?url=https://api.ipify.org"
Headers / parametre
| Hvor | Navn | Krævet | Forklaring |
|---|---|---|---|
| NPM (header) | X-WEIRCON-RANDOM-IP |
ja | API-key. Verificeres af nginx og strippes før forward. |
| Header eller query | X-WEIRCON-RANDOM-IP-REDIRECT/?url= |
ja | Mål-URL der skal hentes. Header har præcedens over query. |
| Header | X-WEIRCON-PROXY-ID |
nej | 0-9. Hvis udeladt: random. |
| Header | X-WEIRCON-FORWARD-METHOD |
nej | HTTP-metode mod target. Default: samme som indkommende. |
| Body | passthrough | nej | Body videresendes som-er hvis metoden er POST/PUT/PATCH. |
Response
Status + headers + body fra upstream returneres direkte. Plus X-WEIRCON-EGRESS-PROXY: <id> så klient kan se hvilken tunnel der blev brugt.
Komponenter
| Sti | Formål |
|---|---|
service/main.go |
Go fetch-service (statisk binary, kører i hoved-netns i LXC'en). |
service/Makefile |
make build → 6MB static binary; make install til /usr/local/bin. |
lxc/setup-host.md |
Proxmox-side: pct create, TUN passthrough, push-kommandoer. |
lxc/setup-container.sh |
Kører inde i LXC'en: apt-deps, microsocks, helper-scripts, units. |
lxc/netns-up.sh |
Bringer ét namespace op: proxy<N> med wg0 + veth + bridge. |
lxc/netns-down.sh |
River det ned igen (kaldes af systemd ExecStopPost). |
lxc/systemd/weircon-proxies.target |
Grouping target for alle 10 tunneler. |
lxc/systemd/weircon-proxy@.service |
Templated unit. enable weircon-proxy@{0..9}.service. |
lxc/systemd/weircon-fetch.service |
Selve fetch-servicen. Hardened (DynamicUser, no caps). |
lxc/fetch.env.example |
Default env til fetch-servicen — kopieres til /etc/weircon-random-proxy/fetch.env. |
npm/advanced.conf |
NPM "Advanced" tab snippet: header-check + strip + forward. |
wg-configs/ |
Lokal placeholder. Selve .conf-filerne lever på LXC'en, ikke i git. |
NPM-laget (kort)
I NginxProxyManager → din proxy host → Advanced tab indsættes en config der:
- Tjekker
$http_x_weircon_random_ipmod den forventede API-key. - Returnerer
401hvis den ikke matcher. - Stripper headeren med
proxy_set_header X-WEIRCON-RANDOM-IP "";før forward. - Forwarder til LXC'ens interne IP på port 8080.
Detaljer + færdig snippet ligger i npm/advanced.conf.
Service-detaljer (Go)
net/http/httputil.ReverseProxyhåndterer body-streaming chunked uden buffering.- Én
*http.Transportpr. tunnel → connection-pool genbruges pr. Proton-egress. golang.org/x/net/proxy.SOCKS5ContextDialer på hver Transport.- Statisk binary (
CGO_ENABLED=0), ~6MB, ingen runtime deps i LXC'en. - Env-vars:
WEIRCON_LISTEN,WEIRCON_PROXY_COUNT,WEIRCON_PROXY_BASE_PORT,WEIRCON_PROXY_HOST,WEIRCON_REQUEST_TIMEOUT_SEC.
Build + smoke-test:
cd service && make build
./weircon-random-proxy # lytter på :8080, peger på 127.0.0.1:25400..25409
Deploy-flow (one-shot)
På din dev-maskine:
cd random_proxy/service && make build # → ./weircon-random-proxy (6MB static)
På Proxmox-hosten følges lxc/setup-host.md:
pct createmed--unprivileged 1 --features nesting=1,keyctl=1(Debian 12).- Tilføj TUN passthrough i
/etc/pve/lxc/<ctid>.conf. pct pushbinary, scripts, units, og dine Proton WG-configs.pct enter <ctid> && bash /root/setup-container.sh.systemctl enable --now weircon-proxies.target weircon-proxy@{0..9}.service weircon-fetch.service.- I NPM: opret host der peger på LXC:8080, indsæt
npm/advanced.confi Advanced-tabben med din API-key.
Status
- Arkitektur dokumenteret
service/Go fetch-service (kompilerer, vet clean, smoke-tested)lxc/netns scripts + systemd units + setup-guidesnpm/advanced.confnginx-snippet til NPM- Faktisk deploy på Proxmox (kræver din host)
- Migrationsnote i
nh-scrape/proxy-stack/der peger hertil - Opdater
nh-scrapetil at kalde den nye endpoint
Open questions
- API-key opbevaring: env-var i NPM, eller en fil mountet ind? (Foreslår env-var via NPM stack.)
- Rate limiting / concurrency: skal vi cap'e samtidige requests pr. tunnel? Proton accepterer ikke ubegrænset.
- Logging: hvor meget skal logges (URL, status, tunnel-id)? Husk GDPR hvis det rammer personhenførbare URL'er.
- Failover: hvis valgt tunnel er nede, fall back til random anden, eller fejl 503?
Description