Some promising improvements on Full Tunnel

[behnamgolds]

Hello everyone,
So I was struglling with Full tunnel as reported in a previous thread (#950 ). Today I was thinking to myself why some has success and some like me can not get it to work?
I come from a networking background and been using linux since 2007 as my main drive. I don't say this to boost my ego, just want to rule out the PEBKAC to some degree.

I thought what if my VPS (France OVH) has some infrastracture problems and no matter what I do on the server side I do not see any improvements?!
I don't want to bore you to death, I came up with a solution, a tunnel (without a second VPS) was what I needed to rule out the infrastracture problems (or at least I hoped so). My two options was an HE ipv6 tunnel , and a cloudflare ZeroTrust tunnel. I chose the second one and guess what , after pointing a dns record to localhost:8080 on the cloudflare connector, I finally saw some improvements, On android I can open Youtube , whatsapp and telegram. I do not have instagram so I let it to you to test. Telegram app on android is still laggy as expected (so many micro transactions happening behind the scene) and whatsapp calls are the same. But hey at least it is usable right now, maybe we could make it better.

The plus of it is this way you do not need to open the tunnel port globally and just listening on localhost:8080 would suffice, another one is you do not need a certificate since cloudflare automatically assigns one to you for each added domain. You can just put https://fwd.example.com in your CodeFull.gs .

Forgot to say, I run the latest versions (1.9.34) both on my phone and on the server .
I had almost the same problem with GooseRelayVPN they both are working, but the GooseRelayVPN gives the best speed right now.

[dazzling-no-more]

@behnamgolds Could you please also check this fork?
https://github.com/dazzling-no-more/rahgozar

[behnamgolds]

@dazzling-no-more ,thanks for your suggestion, I saw some of your PR's on the main project too, so thanks again for your contribution. I checked your fork today, (I used your CodeFull.gs, the client and the tunnel software too). everything else stayed the same as I described in the first post. But with your fork the httpbin.org/ip did not open. This is the first thing I check with curl, and the last If it fails, these days I test about 4 methods to gain access to the free (as in freedom) internet. But I will watch your fork and test again in a few days.

Forgot to say, I checked the appimage too , but It gave some errors about gtk modules:

Gtk-Message: 20:08:21.178: Failed to load module "xapp-gtk3-module"
Gtk-Message: 20:08:21.183: Failed to load module "xapp-gtk3-module"
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

a blank window opens(no controls inside).

I am not a fan of GUIs if there is a fine CLI version anyway, but I think some dependencies managed to escape your appimage.

[therealaleph]

Thanks, this is a useful data point. Cloudflare Tunnel in front of tunnel-node is an interesting deployment shape because it removes the need to expose the tunnel port directly and gives users automatic TLS, which is a real operational win.

I would not document it as a default path yet, though, because it changes several variables at once:

• exit IP / routing may change through Cloudflare infrastructure;
• long-lived tunnel behavior may differ from a direct VPS connection;
• Cloudflare can still apply abuse/risk logic, especially for high-volume or unusual traffic;
• latency may improve or worsen depending on region and ISP path.

If you can, please add a small comparison with the same client and same VPS:

direct tunnel-node URL:
Cloudflare Tunnel URL:
target tested:
httpbin.org/ip result:
rough first-load time:
failure mode, if any:

That would make this actionable as a docs/update candidate instead of just an anecdotal workaround.

---

Answered via LLM, Supervised @therealaleph

[dazzling-no-more]

@dazzling-no-more ,thanks for your suggestion, I saw some of your PR's on the main project too, so thanks again for your contribution. I checked your fork today, (I used your CodeFull.gs, the client and the tunnel software too). everything else stayed the same as I described in the first post. But with your fork the httpbin.org/ip did not open. This is the first thing I check with curl, and the last If it fails, these days I test about 4 methods to gain access to the free (as in freedom) internet. But I will watch your fork and test again in a few days.

Forgot to say, I checked the appimage too , but It gave some errors about gtk modules:

Gtk-Message: 20:08:21.178: Failed to load module "xapp-gtk3-module"
Gtk-Message: 20:08:21.183: Failed to load module "xapp-gtk3-module"
Could not create default EGL display: EGL_BAD_PARAMETER. Aborting...

a blank window opens(no controls inside).

I am not a fan of GUIs if there is a fine CLI version anyway, but I think some dependencies managed to escape your appimage.

The Cloudflare Zero Trust tunnel idea is genuinely clever — you sidestep the public-port exposure and the cert hassle in one move, and it isolates the test from any infrastructure flakiness on the OVH side. I'd actually like to add a section about this pattern to the docs once we figure out why my fork misbehaved for you.

On httpbin.org/ip not opening through my fork: that's almost certainly not the Full-tunnel transport. Combined with what you say next about the AppImage rendering blank, I think what actually happened is: the GUI never came up, so you never got to set mode = "full" and pick your Apps Script deployment. A non-configured client will fall through to whatever the previous config said, or refuse to connect through the relay at all — and curl-to-httpbin via the local proxy in that state would absolutely fail.

Two ways to confirm:

1. Skip the GUI entirely. There's a CLI build for Linux: rahgozar-linux-amd64.tar.gz (and the musl variant if you prefer it static). It's the same binary the AppImage wraps, minus the WebView. Drop a config file next to it (or pass --config path.toml); the schema matches what the GUI writes. Run with RUST_LOG=info (or debug if you want every CONNECT) and you'll see immediately what mode it's in and where requests are going. If httpbin.org/ip still fails through the CLI with mode = "full", that would be a real regression worth digging into and I'd want the log.

2. If you'd rather stick with the AppImage, the EGL_BAD_PARAMETER + blank window is a WebKitGTK rendering issue, not a missing-bundled-dep one (the xapp-gtk3-module warning is just Mint/Cinnamon theme integration being absent and is harmless). Two env vars fix it on the systems I've seen it on:

   WEBKIT_DISABLE_COMPOSITING_MODE=1 ./rahgozar_2.9.1_amd64.AppImage
   # or, if that's not enough:
   WEBKIT_DISABLE_DMABUF_RENDERER=1 ./rahgozar_2.9.1_amd64.AppImage
   

   One or the other almost always gets the window to paint. (Tauri/webkit2gtk picks a renderer based on probed GPU caps and on a chunk of distros, especially anything with NVIDIA proprietary or running in a VM, that probe lies.)

If after one of those routes you still see httpbin.org/ip fail with mode = "full", please grab the RUST_LOG=debug output for that one request, that'd tell me whether it's dying at the Apps Script call, in the relay's CONNECT, or in the local proxy itself. I appreciate you actually testing the fork and reporting back.

[behnamgolds]

@therealaleph "anecdotal workaround" is exactly what I was aiming for. For anyone who wants to test different workarounds, and maybe turn it into something useful for all or let it die in peace .
I might fiddle around a bit more and see if it is worth the effort, or chase the next shiny thing (cloudflare workers vpc seems interesting too!)

[behnamgolds]

@dazzling-no-more I used the CLI version first and then tested the appimage out of curiosity.
I tested the appimage 2.9.0 from yesterday and setting those env variables separately or combined did not solve the problem.