Tunnel Node behind NGINX(and also directly) is very slow

[behnamgolds]

Hi,
I'v setup the tunnel node on my VPS(France) , I have nginx with letsencrypt certificate in place and it is working and receives requests as expected, but it is very slow (below 30 Kilobytes/s) compared to my other apps_script and cloudflare worker setup.
I was checking the logs of my nginx setup today(/var/log/nginx/error.log) where I see lots of warnings like this:

[warn] 6736#6736: *813 an upstream response is buffered to a temporary file /var/lib/nginx/tmp/proxy/5/04/0000000045 while reading upstream, client: 34.116.28.165, server: fwd.mydomain.com, request: "POST /tunnel/batch HTTP/1.1", upstream: "http://127.0.0.1:8080/tunnel/batch", host: "fwd.mydomain.com"

and in my mhrv-rs(version 1.9.18) I see error logs like this:

ERROR batch failed (script AKfycbx-): got the v1.8.0 decoy/placeholder body — could be (1) AUTH_KEY mismatch between mhrv-rs config and Code.gs (run a direct curl probe against the deployment to verify), (2) Apps Script execution timeout or per-100s quota tear (try lowering parallel_concurrency in config), (3) Apps Script internal hiccup (transient, retry next batch), or (4) ISP-side response truncation (#313 pattern, try a different google_ip). To distinguish (1) from the rest: set DIAGNOSTIC_MODE=true at the top of Code.gs + redeploy as new version — only AUTH_KEY mismatch returns this body in diagnostic mode.

I also tried the set up without nginx and on the default 8080 port (my.vps.ip.address:8080). I don't think it is related to nginx since using the tunnel node directly gives the same results, but I thought maybe there is something useful in the nginx log above .

I have three seperate Code.gs deployments(different accounts) in place all with the same config, I double checked the AUTH_KEY, and they all match my config.js file. And I do not know about another google_ip that works (just the one that nslookup returns) . But I don't think it is related to the google_ip or google sni either, since my apps_script and cloudflare setups use the same ip and sni. My guess is there is something wrong between the Code.gs and my vps.

Some rare occasions I see a spike in loading speed around 2 or 3 Mgabytes/Sec but quickly it slumps below 30 Kilobytes/s .

Do you know what the problem is and how to solve it?

[ehsan272727]

I also did the VPS method fo Full tunnel mode and it just doesn't work

[behnamgolds]

I also did the VPS method fo Full tunnel mode and it just doesn't work

@ehsan272727 create a new issue and provide more info (logs, versions, etc..) .
There is a big green button at the top right corner of this page.

[therealaleph]

Reviewed via Anthropic Claude.

@behnamgolds — useful data point. Two separate things in your report:

1. nginx proxy_buffering warning (the temp-file write):
That warning is informational, not the root cause of the 30 KB/s. It means the tunnel-node response exceeded proxy_buffer_size (default 4-8 KB depending on platform) so nginx spilled to disk. For a relay where every batch can be up to 32 MiB (after v1.9.16's BATCH_RESPONSE_BUDGET), that's expected. To eliminate it, increase nginx's buffer config for this server block:

server {
  # ... your existing config ...

  location /tunnel/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_request_buffering off;          # stream client → upstream
    proxy_buffering off;                  # stream upstream → client
    proxy_max_temp_file_size 0;           # disable disk spill entirely
    proxy_read_timeout 360s;              # match Apps Script's 6-min cap
    proxy_send_timeout 360s;
    client_max_body_size 64m;             # batch can be ~32 MiB after base64
  }
}

The two proxy_*_buffering off directives are the important ones — without them, nginx sits on the entire batch before forwarding, defeating the point of streaming.

2. The v1.8.0 decoy/placeholder body (the one you got even WITHOUT nginx):
This is the actual perf killer. Code.gs returns this body when its UrlFetchApp.fetch(TUNNEL_SERVER_URL) call throws an exception — timeout, connection refused, response too large, etc. mhrv-rs's error message lists 4 possible causes:

Given your specific setup (nginx, France VPS, 30 KB/s, 3 deployments), the likely cause is response-size: Apps Script UrlFetchApp has a hard 50 MiB response body cap. If your tunnel-node returns a batch larger than 50 MiB, UrlFetchApp throws, Code.gs's try/catch sends the decoy. v1.9.16 added a 32 MiB total-batch budget on the tunnel-node side specifically to prevent this; if you're on v1.9.18 + recent tunnel-node:latest Docker image, that should hold.

Diagnostic steps that would narrow it down:

1. Direct curl probe against your deployment (not via mhrv-rs):

   curl -v -X POST https://script.google.com/macros/s/<deployment>/exec \
     -H "Content-Type: application/json" \
     -d '{"k":"YOUR_AUTH_KEY","ops":[{"op":"ping"}]}'

   • If you get JSON {"results":[{"r":"pong"}]} → AUTH_KEY is fine and Code.gs ↔ tunnel-node is reachable. The slowness is somewhere in the streaming.
   • If you get the decoy HTML → AUTH_KEY mismatch OR tunnel-node URL wrong inside Code.gs (TUNNEL_SERVER_URL constant).

2. Watch tunnel-node logs while running mhrv-rs:

   docker logs -f mhrv-tunnel

   When the slowdown / decoy error fires in mhrv-rs, what's tunnel-node's log line at the same moment? Is it returning a successful batch JSON (size?) or erroring?

3. Pull tunnel-node:latest again — you might be on an older image. v1.9.16+ has the BATCH_RESPONSE_BUDGET fix for updating steam on full mode #863:

   docker pull ghcr.io/therealaleph/mhrv-tunnel-node:latest
   docker stop mhrv-tunnel && docker rm mhrv-tunnel
   docker run -d --name mhrv-tunnel --restart unless-stopped -p 8080:8080 \
     -e TUNNEL_AUTH_KEY="$SECRET" ghcr.io/therealaleph/mhrv-tunnel-node:latest

4. France VPS routing: Apps Script runs on Google's network. If your tunnel-node is in France and Apps Script's regional edge (often US/EU) routes to it through congested transit, you'll see slow batches. The مشکل حالت فول تانل vps از نسخه ۱.۹.۱۵ به بعد #924 thread has a hypothesis that nginx-as-reverse-proxy interacts badly with h2 inner connections in v1.9.15+ — could be relevant here even on the without-nginx case if there's some intermediate Cloudflare / OVH / Hetzner network policy.

Pinning #924 as the canonical Full Tunnel slowness tracker. Could you post:

• nginx config (redacted) — or note that you tested without it
• tunnel-node Docker image SHA: docker inspect mhrv-tunnel | grep -i image
• mhrv-rs log around the decoy error (5 lines before, 5 after) so we can see which sites / batch sizes are correlated with the failures

Leaving open as one of the canonical Full Tunnel slowness reports. Thanks for the detailed nginx logs — exactly what we needed.