Feature Request: Support Cloudflare WARP as an Outbound for Geo-blocking and Captcha Mitigation

[w0l4i]

Issue Description:
Is your feature request related to a problem? Please describe.
Currently, tunnel-node egresses traffic directly via the VPS main IP. This presents a significant hurdle for users in two ways:

Cloudflare/Google CAPTCHAs: Most VPS IP ranges have a poor reputation. Users frequently encounter endless cf-captcha loops or are outright blocked by websites using Cloudflare security layers.

Geo-restrictions: VPS IPs are often flagged as "Datacenter" IPs, preventing access to region-locked services (Streaming, AI tools, etc.).

Since I (and many others) haven't routed the entire system traffic through WARP yet, having the tunnel itself handle this would be a lifesaver.

Describe the solution you'd like
I suggest implementing an Outbound Configuration for tunnel-node. Specifically:

SOCKS5 Outbound Support: Allow the node to forward its egress traffic to a local SOCKS5 proxy (like a local WARP-CLI instance running on port 4000).

Direct WARP Integration (Optional but preferred): A native way to define a WARP/WireGuard outbound within the configuration file to rotate or clean the exit IP.

This would allow the tunnel to act as a bridge while the actual "exit" to the internet happens through a clean Cloudflare IP, effectively solving the CAPTCHA and blocking issues.

Describe alternatives you've considered
Setting up a global WARP interface on the OS level is an option, but it often breaks SSH connections or interferes with other services on a technical specialist's server. A per-application outbound is much more robust.

Additional context
This feature is crucial for maintaining the usability of the MasterHttpRelayVPN project in environments with strict filtering and aggressive bot-detection systems.

MODE: FULL (TUNNEL NODE > WARP)

[w0l4i]

stocking at captcha that warp can easily fix it

[therealaleph]

@w0l4i — solid feature request, well-articulated. Cloudflare WARP as tunnel-node outbound is a clean architectural win:

What it would change:

Current:
  tunnel-node → VPS-IP (datacenter-flagged) → origin
  
With WARP:
  tunnel-node → WARP client → Cloudflare-residential-IP → origin

WARP IPs are Cloudflare consumer ranges that Cloudflare's own security layers don't penalize. From an origin server's POV, traffic looks like it came from a regular Cloudflare consumer, not a datacenter VPS. That sidesteps:

• Cloudflare cf-captcha loops
• Datacenter-IP heuristic that hits Instagram, Meta, OpenAI, OpenRouter, etc.
• Some geo-restrictions (WARP IPs aren't always region-locked the same way)

Implementation paths:

Option A: Document setup, no code change. WARP is already a standalone Linux client. Users can install it on their VPS:

# On VPS (after tunnel-node is running)
curl https://pkg.cloudflareclient.com/install.sh | sudo bash
warp-cli register
warp-cli connect

# Verify outbound goes via WARP
curl https://www.cloudflare.com/cdn-cgi/trace
# Should show 'warp=on'

This routes the VPS's entire outbound through WARP. tunnel-node automatically benefits without any mhrv-rs code changes. Trade-off: VPS's own incoming connections (the Apps Script→VPS hop) still work because incoming isn't affected by WARP, only outgoing.

We could ship this as a docs/tunnel-node-warp.md guide. ~30 min of doc work.

Option B: tunnel-node integrates a WARP client library. Bigger surface area — would need to bundle WARP's WireGuard tunnel as a Rust dep, manage WARP credentials, handle reconnects. Probably 200-400 LOC + ongoing maintenance for WARP API drift.

My recommendation: Option A first. Ships in days, gets users the benefit immediately, no maintenance burden. Option B is only worth doing if Option A turns out to be insufficient (e.g., per-flow routing instead of all-VPS-traffic).

Caveats:

• WARP+ (paid tier) gives more bandwidth and stability than free WARP. Free WARP throttles after sustained heavy use. For a tunnel-node with multiple users, WARP+ ($5/month) may be necessary.
• WARP doesn't accept incoming connections by default — the VPS's tunnel-node listener is fine because that's the server side, but if you need outbound P2P (e.g., direct-connect VoIP) that won't work with stock WARP.
• Some sites detect WARP and treat it the same as a VPN (not common, but happens). For those, you'd want to disable WARP for those specific destinations — which is back to needing per-flow routing.

Tracking as v1.8.x roadmap item — likely Option A docs first, Option B if demand justifies. If you want to take Option A as a PR (write the docs/tunnel-node-warp.md), happy to review.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

@w0l4i — solid feature request, well-articulated. Cloudflare WARP as tunnel-node outbound is a clean architectural win:

What it would change:

Current:
  tunnel-node → VPS-IP (datacenter-flagged) → origin
  
With WARP:
  tunnel-node → WARP client → Cloudflare-residential-IP → origin

WARP IPs are Cloudflare consumer ranges that Cloudflare's own security layers don't penalize. From an origin server's POV, traffic looks like it came from a regular Cloudflare consumer, not a datacenter VPS. That sidesteps:

• Cloudflare cf-captcha loops
• Datacenter-IP heuristic that hits Instagram, Meta, OpenAI, OpenRouter, etc.
• Some geo-restrictions (WARP IPs aren't always region-locked the same way)

Implementation paths:

Option A: Document setup, no code change. WARP is already a standalone Linux client. Users can install it on their VPS:

# On VPS (after tunnel-node is running)
curl https://pkg.cloudflareclient.com/install.sh | sudo bash
warp-cli register
warp-cli connect

# Verify outbound goes via WARP
curl https://www.cloudflare.com/cdn-cgi/trace
# Should show 'warp=on'

This routes the VPS's entire outbound through WARP. tunnel-node automatically benefits without any mhrv-rs code changes. Trade-off: VPS's own incoming connections (the Apps Script→VPS hop) still work because incoming isn't affected by WARP, only outgoing.

We could ship this as a docs/tunnel-node-warp.md guide. ~30 min of doc work.

Option B: tunnel-node integrates a WARP client library. Bigger surface area — would need to bundle WARP's WireGuard tunnel as a Rust dep, manage WARP credentials, handle reconnects. Probably 200-400 LOC + ongoing maintenance for WARP API drift.

My recommendation: Option A first. Ships in days, gets users the benefit immediately, no maintenance burden. Option B is only worth doing if Option A turns out to be insufficient (e.g., per-flow routing instead of all-VPS-traffic).

Caveats:

• WARP+ (paid tier) gives more bandwidth and stability than free WARP. Free WARP throttles after sustained heavy use. For a tunnel-node with multiple users, WARP+ ($5/month) may be necessary.
• WARP doesn't accept incoming connections by default — the VPS's tunnel-node listener is fine because that's the server side, but if you need outbound P2P (e.g., direct-connect VoIP) that won't work with stock WARP.
• Some sites detect WARP and treat it the same as a VPN (not common, but happens). For those, you'd want to disable WARP for those specific destinations — which is back to needing per-flow routing.

Tracking as v1.8.x roadmap item — likely Option A docs first, Option B if demand justifies. If you want to take Option A as a PR (write the docs/tunnel-node-warp.md), happy to review.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

option a not good recommendation because using cloudflare warp cli to tunnel all vps traffic will make it unusable and ssh connection will be effected by this
i have another proposal for this :
just add an choosable upstream interface to node tunnel code that can be enable through .env for docker that will route the traffic to warp interface
for example i have run the cloud flare warp as interface warp then i need to change the --upstream-interface : warp in container .env so upstream goes to warp like this :
tunnel node container > upstream interface flag : warp > warp
best case scenario with lowest code changes
best regards

[therealaleph]

@w0l4i — agreed, your counter-proposal is much cleaner than my Option A. The issue with WARP-as-default-route on the VPS (breaking SSH + the inbound Apps Script→VPS hop) is real and your --upstream-interface warp approach side-steps it entirely.

Updated design (as you proposed):

User installs WARP on the VPS as a separate interface (warp device, not as default route). tunnel-node binds outgoing sockets specifically to that interface via SO_BINDTODEVICE. SSH and tunnel-node's listener still use the default route.

# On VPS:
warp-cli connect       # creates interface "warp", does NOT change default route
ip link show warp      # verify the interface exists

# tunnel-node config:
docker run -d --name mhrv-tunnel \
  --restart unless-stopped \
  --network host \  # need host networking for SO_BINDTODEVICE to see warp
  -p 8443:8443 \
  -e MHRV_AUTH_KEY="$(openssl rand -hex 32)" \
  -e UPSTREAM_INTERFACE="warp" \  # NEW
  ghcr.io/therealaleph/mhrv-tunnel-node:latest

Implementation in tunnel-node: small surface area. Roughly:

// In TcpStream::connect path of tunnel-node:
let sock = TcpSocket::new_v4()?;
if let Some(iface) = config.upstream_interface.as_ref() {
    // Linux only — SO_BINDTODEVICE requires CAP_NET_RAW or root
    let iface_cstr = std::ffi::CString::new(iface.as_str())?;
    unsafe {
        libc::setsockopt(
            sock.as_raw_fd(),
            libc::SOL_SOCKET,
            libc::SO_BINDTODEVICE,
            iface_cstr.as_ptr() as *const _,
            iface.len() as libc::socklen_t,
        );
    }
}
sock.connect(addr).await?

Plus equivalent for UDP for udpgw flows. ~50 LOC + env-var plumbing + Dockerfile capability docs (the container needs CAP_NET_RAW to use SO_BINDTODEVICE).

Trade-offs:

• Linux-only. SO_BINDTODEVICE doesn't exist on macOS/Windows. tunnel-node ships as Linux Docker so this is fine — but we'd need to feature-gate or make it a no-op when the env var is unset.
• Capability requirement. Container needs CAP_NET_RAW. Adds --cap-add=NET_RAW to the docker run.
• Per-flow routing not free. All outbound from tunnel-node goes via warp. If you want some flows direct (e.g. low-latency Google), need a richer routing rule. For v1, "all outbound via warp" is the simple default; finer-grained = follow-up.

This is genuinely better than Option A — happy to take this as the v1.8.x WARP support landing point.

If you want to take a PR (you've done good work on the longpoll fix in #290 / #319 area), I'll happily review. Roughly the changes:

1. tunnel-node/src/main.rs — read UPSTREAM_INTERFACE env var into config
2. tunnel-node/src/connect.rs (or wherever the outbound TCP/UDP connect lives) — apply SO_BINDTODEVICE if config set
3. tunnel-node/Dockerfile — document capability need; maybe add RUN setcap cap_net_raw+ep so non-root works
4. tunnel-node/README.md — short "WARP outbound" section explaining the install + run flow
5. (No mhrv-rs client changes needed — this is tunnel-node-only)

Otherwise I'll plan to ship it myself in the v1.8.x cycle. Tracked.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

@w0l4i — agreed, your counter-proposal is much cleaner than my Option A. The issue with WARP-as-default-route on the VPS (breaking SSH + the inbound Apps Script→VPS hop) is real and your --upstream-interface warp approach side-steps it entirely.

Updated design (as you proposed):

User installs WARP on the VPS as a separate interface (warp device, not as default route). tunnel-node binds outgoing sockets specifically to that interface via SO_BINDTODEVICE. SSH and tunnel-node's listener still use the default route.

On VPS:

warp-cli connect # creates interface "warp", does NOT change default route
ip link show warp # verify the interface exists

tunnel-node config:

docker run -d --name mhrv-tunnel
--restart unless-stopped
--network host \ # need host networking for SO_BINDTODEVICE to see warp
-p 8443:8443
-e MHRV_AUTH_KEY="$(openssl rand -hex 32)"
-e UPSTREAM_INTERFACE="warp" \ # NEW
ghcr.io/therealaleph/mhrv-tunnel-node:latest
Implementation in tunnel-node: small surface area. Roughly:

// In TcpStream::connect path of tunnel-node:
let sock = TcpSocket::new_v4()?;
if let Some(iface) = config.upstream_interface.as_ref() {
// Linux only — SO_BINDTODEVICE requires CAP_NET_RAW or root
let iface_cstr = std::ffi::CString::new(iface.as_str())?;
unsafe {
libc::setsockopt(
sock.as_raw_fd(),
libc::SOL_SOCKET,
libc::SO_BINDTODEVICE,
iface_cstr.as_ptr() as *const _,
iface.len() as libc::socklen_t,
);
}
}
sock.connect(addr).await?
Plus equivalent for UDP for udpgw flows. ~50 LOC + env-var plumbing + Dockerfile capability docs (the container needs CAP_NET_RAW to use SO_BINDTODEVICE).

Trade-offs:

• Linux-only. SO_BINDTODEVICE doesn't exist on macOS/Windows. tunnel-node ships as Linux Docker so this is fine — but we'd need to feature-gate or make it a no-op when the env var is unset.
• Capability requirement. Container needs CAP_NET_RAW. Adds --cap-add=NET_RAW to the docker run.
• Per-flow routing not free. All outbound from tunnel-node goes via warp. If you want some flows direct (e.g. low-latency Google), need a richer routing rule. For v1, "all outbound via warp" is the simple default; finer-grained = follow-up.

This is genuinely better than Option A — happy to take this as the v1.8.x WARP support landing point.

If you want to take a PR (you've done good work on the longpoll fix in #290 / #319 area), I'll happily review. Roughly the changes:

1. tunnel-node/src/main.rs — read UPSTREAM_INTERFACE env var into config
2. tunnel-node/src/connect.rs (or wherever the outbound TCP/UDP connect lives) — apply SO_BINDTODEVICE if config set
3. tunnel-node/Dockerfile — document capability need; maybe add RUN setcap cap_net_raw+ep so non-root works
4. tunnel-node/README.md — short "WARP outbound" section explaining the install + run flow
5. (No mhrv-rs client changes needed — this is tunnel-node-only)

Otherwise I'll plan to ship it myself in the v1.8.x cycle. Tracked.

[reply via Anthropic Claude | reviewed by @therealaleph]

i will wait for 1.8.x release for this tnx btw

[2bemoji]

I strongly support this. Most VPS providers are currently in a 'reputation debt'—their IP ranges are pre-flagged by IP Intelligence services as Datacenter/Proxy. This leads to the 'Captcha Hell' many users are experiencing.

Adding a SOCKS5/WireGuard outbound allows for Application-Level Routing. This is significantly safer than a global OS-level WARP configuration, which often risks breaking SSH access due to asymmetric routing issues. By exiting through Cloudflare's Anycast network, we leverage their high IP reputation to bypass aggressive bot-detection and Geo-fencing that wouldn't otherwise trust a standard VPS IP."
@w0l4i @therealaleph