[Performance/Enhancement] High Latency and Timeouts in "mode: full" via Google App Script (GAS)

[w0l4i]

🚀 Enhancement Request: Optimizing "mode: full" Performance and Stability in Large-Scale GAS Deployments

I am using MasterHttpRelayVPN in mode: full with a multi-account architecture to bypass restrictions. My setup is as follows:

• Architecture: Client > 7x Google Apps Script (GAS) Deployments (using 7 distinct Google accounts) > Node Nginx > Tunnel Container.
• Concurrency: Utilizing parallel dispatching with a factor of 2-3 across these 7 deployments.

📉 The Problem: Bottleneck in Client Dispatching

Despite distributing the load across 7 independent GAS deployments, I am observing high latency and frequent connection timeouts. The current implementation of the Rust client seems to struggle with managing these concurrent requests efficiently, particularly when the network or Google's endpoints face momentary congestion.

The logs consistently show long RTT spikes leading to os error 10060. Instead of failing over to other healthy GAS deployments, the client appears to wait for the stalled request to time out, which creates a "blocking" effect that degrades the entire tunnel's performance.

Log evidence:

2026-04-26T15:20:32.688953Z  INFO batch: 1 ops → AKfycbwA, rtt=21.0450168s
2026-04-26T15:20:32.688974Z  WARN batch failed: io: A connection attempt failed ... (os error 10060)
2026-04-26T15:20:34.877856Z  INFO batch: 1 ops → AKfycbwA, rtt=21.0389911s
2026-04-26T15:20:34.877877Z  WARN batch failed: io: A connection attempt failed ... (os error 10060)

💡 Suggested Optimizations
To effectively utilize parallel deployments and resolve these bottlenecks, I suggest the following refactorings:

1. "Fail-Fast" Dispatcher & Timeout Logic
Waiting 21 seconds for a batch to fail is unacceptable for real-time traffic.

Proposal: Implement a configurable request_timeout (e.g., 5-8 seconds). If a request to a specific GAS Deployment ID exceeds this limit, the client should treat it as a failure, mark that deployment as "temporarily degraded," and offload the batch to the next available deployment immediately.

2. Deployment Health-Scoring System
With 7 deployments in use, the client needs better awareness of backend health.

Proposal: Introduce a simple scoring or weight system for the Deployment ID list. If a deployment triggers a timeout, it should be penalized (cooldown period) and removed from the rotation for a few minutes. This prevents the client from repeatedly hitting a throttled or slow account.

3. Optimized Flush Interval (Batch Muxer)
Proposal: The current batching logic appears to be too conservative, contributing to unnecessary latency. Please make max_batch_size and flush_interval tunable parameters. For mode: full, we need a more aggressive flush strategy to ensure that traffic is not unnecessarily queued when RTT is high.

4. Persistent Connection Pooling
Proposal: Ensure that the Rust HTTP client (using reqwest or hyper) is configured to maintain keep-alive connections to all 7 GAS endpoints. Currently, if the client performs a new TLS handshake for every batch request across 7 accounts, the overhead is massive. Maintaining persistent TCP tunnels to each Google front-end is critical for performance.

🏁 Conclusion
The current multi-account setup shows great potential, but the client-side dispatching logic is holding it back by treating all endpoints as equally reliable regardless of their real-time performance. Implementing these changes will transform mode: full into a much more stable and responsive tunneling solution.

I am highly motivated to help test these changes. Please let me know if you are open to a PR or need further debugging information.

[w0l4i]

@claude @therealaleph

[therealaleph]

@w0l4i — fantastic report. All four of your suggestions land on real architectural gaps. Let me confirm what I see in the code and what I'm willing to ship:

Diagnosis (all four points are real):

1. BATCH_TIMEOUT = 30s is too long. From src/tunnel_client.rs:44. Yes — for typical GAS RTT of 2–7 s, 30 s means we wait 4–10× normal latency before failing over. Should be ~10 s for a "definitely sick" call, configurable for users with fast/slow links. Your 21 s os error 10060 log shows exactly the "stalled forever" symptom this causes.

2. No health-aware deployment selection. fronter.next_script_id() is pure round-robin. With 7 deployments and one degraded, every 7th batch hits it and burns the timeout. Your "concurrency 2-3" makes this worse — at any moment, ~2-3 batches are blocked on the bad deployment.

3. No tunable batch params. MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB, BATCH_COALESCE_WINDOW=8ms — all hard-coded. The 8 ms coalesce was tuned for residential RTT (matters when GAS RTT is 2 s, doesn't really matter when it's 200 ms via your nginx-fronted setup). Should be configurable.

4. Connection pooling status is mixed. We use tokio-rustls and the existing domain_fronter pre-warms TLS connections (you'd see pool pre-warmed with N connection(s) in your log). But: pool is per-DomainFronter, not per-deployment. So the 7 GAS endpoints share one pool which can hit head-of-line on any one being slow.

Proposal — what I'll ship in v1.7.x:

I'll do this in two passes to keep the diff reviewable:

Pass 1 (fast follow-up, v1.7.1):

• New config field: batch_timeout_ms (default 10000, was hardcoded 30000)
• New config field: batch_coalesce_window_ms (default 8, was hardcoded 8 — exposes for users like you to tune)
• New config field: max_batch_ops (default 50, was hardcoded — you might want lower for low-RTT)
• Move all three from const to Config field with serde defaults

This addresses (1) and (3) without architectural change. Minimal blast radius.

Pass 2 (v1.7.2 or v1.8.0):

• next_script_id() becomes health-aware. Each deployment tracks: rolling timeout count + rolling RTT P95.
• A deployment with N timeouts in last M batches → "cooldown" for K seconds (not selected unless all others also degraded)
• A deployment with P95 RTT > 2× cluster median → de-prioritized
• Per-deployment connection pool isolation (separate pre-warmed conns per script_id)

This addresses (2) and (4). Bigger change — wants tests covering the cooldown decay, P95 update, and the "all degraded" fallback.

Interim workaround for your case TODAY:

Until v1.7.1 ships, the cheapest mitigation is to drop the bad deployment manually when you see os error 10060 repeating to the same script_id. Look for the pattern in your logs:

2026-04-26T15:20:32... batch: 1 ops → AKfycbwA, rtt=21.04s
2026-04-26T15:20:34... batch: 1 ops → AKfycbwA, rtt=21.03s

The same script_id (AKfycbwA here) timing out twice → that deployment is throttled or its account is in trouble. Remove it from deployment_ids[] in your config and restart mhrv-rs. The other 6 will pick up the slack without the per-7th blocking.

You can also test whether the issue is your nginx layer or the GAS account itself by curl-ing the deployment URL directly:

curl -s -X POST 'https://script.google.com/macros/s/AKfycbwA.../exec' \
  -H 'Content-Type: application/json' \
  -d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}' \
  --max-time 5

If that 21-second timeout reproduces with curl direct (no mhrv-rs in path), the GAS account is the problem, not our client. If curl returns in <3 s reliably, the issue is somewhere in our nginx/fronter chain.

On your PR offer:

Yes, please. Pass 1 (config fields) is small and self-contained — happy to merge if you'd like to take it. Pass 2 (health-tracking) wants design discussion before implementation; if you want to draft an RFC-style comment on this issue with your proposed data structures (e.g. struct DeploymentHealth { ema_rtt: f64, recent_failures: VecDeque<...>, cooldown_until: Option<Instant> }), happy to iterate from there.

Tracking this issue as the umbrella — when v1.7.1 ships I'll comment with the new config knobs.

---

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

[w0l4i]

@w0l4i — fantastic report. All four of your suggestions land on real architectural gaps. Let me confirm what I see in the code and what I'm willing to ship:

Diagnosis (all four points are real):

1. BATCH_TIMEOUT = 30s is too long. From src/tunnel_client.rs:44. Yes — for typical GAS RTT of 2–7 s, 30 s means we wait 4–10× normal latency before failing over. Should be ~10 s for a "definitely sick" call, configurable for users with fast/slow links. Your 21 s os error 10060 log shows exactly the "stalled forever" symptom this causes.
2. No health-aware deployment selection. fronter.next_script_id() is pure round-robin. With 7 deployments and one degraded, every 7th batch hits it and burns the timeout. Your "concurrency 2-3" makes this worse — at any moment, ~2-3 batches are blocked on the bad deployment.
3. No tunable batch params. MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB, BATCH_COALESCE_WINDOW=8ms — all hard-coded. The 8 ms coalesce was tuned for residential RTT (matters when GAS RTT is 2 s, doesn't really matter when it's 200 ms via your nginx-fronted setup). Should be configurable.
4. Connection pooling status is mixed. We use tokio-rustls and the existing domain_fronter pre-warms TLS connections (you'd see pool pre-warmed with N connection(s) in your log). But: pool is per-DomainFronter, not per-deployment. So the 7 GAS endpoints share one pool which can hit head-of-line on any one being slow.

Proposal — what I'll ship in v1.7.x:

I'll do this in two passes to keep the diff reviewable:

Pass 1 (fast follow-up, v1.7.1):

• New config field: batch_timeout_ms (default 10000, was hardcoded 30000)
• New config field: batch_coalesce_window_ms (default 8, was hardcoded 8 — exposes for users like you to tune)
• New config field: max_batch_ops (default 50, was hardcoded — you might want lower for low-RTT)
• Move all three from const to Config field with serde defaults

This addresses (1) and (3) without architectural change. Minimal blast radius.

Pass 2 (v1.7.2 or v1.8.0):

• next_script_id() becomes health-aware. Each deployment tracks: rolling timeout count + rolling RTT P95.
• A deployment with N timeouts in last M batches → "cooldown" for K seconds (not selected unless all others also degraded)
• A deployment with P95 RTT > 2× cluster median → de-prioritized
• Per-deployment connection pool isolation (separate pre-warmed conns per script_id)

This addresses (2) and (4). Bigger change — wants tests covering the cooldown decay, P95 update, and the "all degraded" fallback.

Interim workaround for your case TODAY:

Until v1.7.1 ships, the cheapest mitigation is to drop the bad deployment manually when you see os error 10060 repeating to the same script_id. Look for the pattern in your logs:

2026-04-26T15:20:32... batch: 1 ops → AKfycbwA, rtt=21.04s
2026-04-26T15:20:34... batch: 1 ops → AKfycbwA, rtt=21.03s

The same script_id (AKfycbwA here) timing out twice → that deployment is throttled or its account is in trouble. Remove it from deployment_ids[] in your config and restart mhrv-rs. The other 6 will pick up the slack without the per-7th blocking.

You can also test whether the issue is your nginx layer or the GAS account itself by curl-ing the deployment URL directly:

curl -s -X POST 'https://script.google.com/macros/s/AKfycbwA.../exec'
-H 'Content-Type: application/json'
-d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}'
--max-time 5
If that 21-second timeout reproduces with curl direct (no mhrv-rs in path), the GAS account is the problem, not our client. If curl returns in <3 s reliably, the issue is somewhere in our nginx/fronter chain.

On your PR offer:

Yes, please. Pass 1 (config fields) is small and self-contained — happy to merge if you'd like to take it. Pass 2 (health-tracking) wants design discussion before implementation; if you want to draft an RFC-style comment on this issue with your proposed data structures (e.g. struct DeploymentHealth { ema_rtt: f64, recent_failures: VecDeque<...>, cooldown_until: Option<Instant> }), happy to iterate from there.

Tracking this issue as the umbrella — when v1.7.1 ships I'll comment with the new config knobs.

[reply via Anthropic Claude | reviewed by @therealaleph]

@therealaleph Thanks for the detailed breakdown! It's great to see we are aligned on the root causes.

Regarding your suggestions:

1. Testing with curl: I performed the direct curl test on the problematic script_id (AKfycbwA). The RTT was consistently high (>15s) even with a simple httpbin request, confirming that the issue is indeed with specific Google accounts being throttled or routed poorly by Google's infrastructure, rather than the client or Nginx layer. This reinforces the need for a health-aware dispatcher.

2. Pass 1 (Config Fields): I'm happy to take this on. I will prepare a PR to move BATCH_TIMEOUT, BATCH_COALESCE_WINDOW, and MAX_BATCH_OPS into the Config struct with appropriate Serde defaults. This will provide immediate relief for users in restrictive environments.

3. Pass 2 (Health-Aware Design): Here is a preliminary draft for the health tracking structure to kick off the discussion:

struct DeploymentHealth {
    ema_rtt: f64,              // Exponential Moving Average of RTT
    recent_failures: u32,      // Counter for consecutive timeouts
    cooldown_until: Option<Instant>, // Timestamp for the penalty period
    last_success: Instant,     // To track idle/dead deployments
}

I suggest a simple logic: If recent_failures > MAX_RETRIES, set cooldown_until to Instant::now() + Duration::from_secs(300). When selecting a script_id, the dispatcher filters for deployments where cooldown_until is None or has passed.

I'll start working on the PR for Pass 1 now. Looking forward to your thoughts on the data structure for Pass 2!

[w0l4i]

@w0l4i — fantastic report. All four of your suggestions land on real architectural gaps. Let me confirm what I see in the code and what I'm willing to ship:

Diagnosis (all four points are real):

1. BATCH_TIMEOUT = 30s is too long. From src/tunnel_client.rs:44. Yes — for typical GAS RTT of 2–7 s, 30 s means we wait 4–10× normal latency before failing over. Should be ~10 s for a "definitely sick" call, configurable for users with fast/slow links. Your 21 s os error 10060 log shows exactly the "stalled forever" symptom this causes.
2. No health-aware deployment selection. fronter.next_script_id() is pure round-robin. With 7 deployments and one degraded, every 7th batch hits it and burns the timeout. Your "concurrency 2-3" makes this worse — at any moment, ~2-3 batches are blocked on the bad deployment.
3. No tunable batch params. MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB, BATCH_COALESCE_WINDOW=8ms — all hard-coded. The 8 ms coalesce was tuned for residential RTT (matters when GAS RTT is 2 s, doesn't really matter when it's 200 ms via your nginx-fronted setup). Should be configurable.
4. Connection pooling status is mixed. We use tokio-rustls and the existing domain_fronter pre-warms TLS connections (you'd see pool pre-warmed with N connection(s) in your log). But: pool is per-DomainFronter, not per-deployment. So the 7 GAS endpoints share one pool which can hit head-of-line on any one being slow.

Proposal — what I'll ship in v1.7.x:

I'll do this in two passes to keep the diff reviewable:

Pass 1 (fast follow-up, v1.7.1):

• New config field: batch_timeout_ms (default 10000, was hardcoded 30000)
• New config field: batch_coalesce_window_ms (default 8, was hardcoded 8 — exposes for users like you to tune)
• New config field: max_batch_ops (default 50, was hardcoded — you might want lower for low-RTT)
• Move all three from const to Config field with serde defaults

This addresses (1) and (3) without architectural change. Minimal blast radius.

Pass 2 (v1.7.2 or v1.8.0):

• next_script_id() becomes health-aware. Each deployment tracks: rolling timeout count + rolling RTT P95.
• A deployment with N timeouts in last M batches → "cooldown" for K seconds (not selected unless all others also degraded)
• A deployment with P95 RTT > 2× cluster median → de-prioritized
• Per-deployment connection pool isolation (separate pre-warmed conns per script_id)

This addresses (2) and (4). Bigger change — wants tests covering the cooldown decay, P95 update, and the "all degraded" fallback.

Interim workaround for your case TODAY:

Until v1.7.1 ships, the cheapest mitigation is to drop the bad deployment manually when you see os error 10060 repeating to the same script_id. Look for the pattern in your logs:

2026-04-26T15:20:32... batch: 1 ops → AKfycbwA, rtt=21.04s
2026-04-26T15:20:34... batch: 1 ops → AKfycbwA, rtt=21.03s

The same script_id (AKfycbwA here) timing out twice → that deployment is throttled or its account is in trouble. Remove it from deployment_ids[] in your config and restart mhrv-rs. The other 6 will pick up the slack without the per-7th blocking.

You can also test whether the issue is your nginx layer or the GAS account itself by curl-ing the deployment URL directly:

curl -s -X POST 'https://script.google.com/macros/s/AKfycbwA.../exec'
-H 'Content-Type: application/json'
-d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}'
--max-time 5
If that 21-second timeout reproduces with curl direct (no mhrv-rs in path), the GAS account is the problem, not our client. If curl returns in <3 s reliably, the issue is somewhere in our nginx/fronter chain.

On your PR offer:

Yes, please. Pass 1 (config fields) is small and self-contained — happy to merge if you'd like to take it. Pass 2 (health-tracking) wants design discussion before implementation; if you want to draft an RFC-style comment on this issue with your proposed data structures (e.g. struct DeploymentHealth { ema_rtt: f64, recent_failures: VecDeque<...>, cooldown_until: Option<Instant> }), happy to iterate from there.

Tracking this issue as the umbrella — when v1.7.1 ships I'll comment with the new config knobs.

[reply via Anthropic Claude | reviewed by @therealaleph]

Hi,

Following our recent discussions, I have completed the refactoring process to fully decouple the system from hardcoded constants.

I have opened two Pull Requests that address these requirements:

#267: Implementation of error detection helpers for connect_data to ensure robust handling when falling back to legacy modes.

#269: Refactoring src/tunnel_client.rs to replace all hardcoded timing constants with dynamic values loaded from the configuration.

Could you please review these PRs? If everything looks correct, please feel free to merge them.

Regarding the remaining roadmap we discussed, I’ll leave the implementation of the next steps to you. Please feel free to proceed with the rest of the tasks according to our plan in this issue.

Thanks for the collaboration!

[w0l4i]

@w0l4i — fantastic report. All four of your suggestions land on real architectural gaps. Let me confirm what I see in the code and what I'm willing to ship:

Diagnosis (all four points are real):

1. BATCH_TIMEOUT = 30s is too long. From src/tunnel_client.rs:44. Yes — for typical GAS RTT of 2–7 s, 30 s means we wait 4–10× normal latency before failing over. Should be ~10 s for a "definitely sick" call, configurable for users with fast/slow links. Your 21 s os error 10060 log shows exactly the "stalled forever" symptom this causes.
2. No health-aware deployment selection. fronter.next_script_id() is pure round-robin. With 7 deployments and one degraded, every 7th batch hits it and burns the timeout. Your "concurrency 2-3" makes this worse — at any moment, ~2-3 batches are blocked on the bad deployment.
3. No tunable batch params. MAX_BATCH_OPS=50, MAX_BATCH_PAYLOAD_BYTES=4 MiB, BATCH_COALESCE_WINDOW=8ms — all hard-coded. The 8 ms coalesce was tuned for residential RTT (matters when GAS RTT is 2 s, doesn't really matter when it's 200 ms via your nginx-fronted setup). Should be configurable.
4. Connection pooling status is mixed. We use tokio-rustls and the existing domain_fronter pre-warms TLS connections (you'd see pool pre-warmed with N connection(s) in your log). But: pool is per-DomainFronter, not per-deployment. So the 7 GAS endpoints share one pool which can hit head-of-line on any one being slow.

Proposal — what I'll ship in v1.7.x:

I'll do this in two passes to keep the diff reviewable:

Pass 1 (fast follow-up, v1.7.1):

• New config field: batch_timeout_ms (default 10000, was hardcoded 30000)
• New config field: batch_coalesce_window_ms (default 8, was hardcoded 8 — exposes for users like you to tune)
• New config field: max_batch_ops (default 50, was hardcoded — you might want lower for low-RTT)
• Move all three from const to Config field with serde defaults

This addresses (1) and (3) without architectural change. Minimal blast radius.

Pass 2 (v1.7.2 or v1.8.0):

• next_script_id() becomes health-aware. Each deployment tracks: rolling timeout count + rolling RTT P95.
• A deployment with N timeouts in last M batches → "cooldown" for K seconds (not selected unless all others also degraded)
• A deployment with P95 RTT > 2× cluster median → de-prioritized
• Per-deployment connection pool isolation (separate pre-warmed conns per script_id)

This addresses (2) and (4). Bigger change — wants tests covering the cooldown decay, P95 update, and the "all degraded" fallback.

Interim workaround for your case TODAY:

Until v1.7.1 ships, the cheapest mitigation is to drop the bad deployment manually when you see os error 10060 repeating to the same script_id. Look for the pattern in your logs:

2026-04-26T15:20:32... batch: 1 ops → AKfycbwA, rtt=21.04s
2026-04-26T15:20:34... batch: 1 ops → AKfycbwA, rtt=21.03s

The same script_id (AKfycbwA here) timing out twice → that deployment is throttled or its account is in trouble. Remove it from deployment_ids[] in your config and restart mhrv-rs. The other 6 will pick up the slack without the per-7th blocking.

You can also test whether the issue is your nginx layer or the GAS account itself by curl-ing the deployment URL directly:

curl -s -X POST 'https://script.google.com/macros/s/AKfycbwA.../exec'
-H 'Content-Type: application/json'
-d '{"k":"YOUR_KEY","u":"https://httpbin.org/get","m":"GET"}'
--max-time 5
If that 21-second timeout reproduces with curl direct (no mhrv-rs in path), the GAS account is the problem, not our client. If curl returns in <3 s reliably, the issue is somewhere in our nginx/fronter chain.

On your PR offer:

Yes, please. Pass 1 (config fields) is small and self-contained — happy to merge if you'd like to take it. Pass 2 (health-tracking) wants design discussion before implementation; if you want to draft an RFC-style comment on this issue with your proposed data structures (e.g. struct DeploymentHealth { ema_rtt: f64, recent_failures: VecDeque<...>, cooldown_until: Option<Instant> }), happy to iterate from there.

Tracking this issue as the umbrella — when v1.7.1 ships I'll comment with the new config knobs.

[reply via Anthropic Claude | reviewed by @therealaleph]

i will wait for your turn , I'm sorry without good internet i can't run test build and this happened please do according to the plan by yourself #263

[w0l4i]

🚀 Enhancement Request: Optimizing "mode: full" Performance and Stability in Large-Scale GAS Deployments

I am using MasterHttpRelayVPN in mode: full with a multi-account architecture to bypass restrictions. My setup is as follows:

• Architecture: Client > 7x Google Apps Script (GAS) Deployments (using 7 distinct Google accounts) > Node Nginx > Tunnel Container.
• Concurrency: Utilizing parallel dispatching with a factor of 2-3 across these 7 deployments.

📉 The Problem: Bottleneck in Client Dispatching

Despite distributing the load across 7 independent GAS deployments, I am observing high latency and frequent connection timeouts. The current implementation of the Rust client seems to struggle with managing these concurrent requests efficiently, particularly when the network or Google's endpoints face momentary congestion.

The logs consistently show long RTT spikes leading to os error 10060. Instead of failing over to other healthy GAS deployments, the client appears to wait for the stalled request to time out, which creates a "blocking" effect that degrades the entire tunnel's performance.

Log evidence:

2026-04-26T15:20:32.688953Z  INFO batch: 1 ops → AKfycbwA, rtt=21.0450168s
2026-04-26T15:20:32.688974Z  WARN batch failed: io: A connection attempt failed ... (os error 10060)
2026-04-26T15:20:34.877856Z  INFO batch: 1 ops → AKfycbwA, rtt=21.0389911s
2026-04-26T15:20:34.877877Z  WARN batch failed: io: A connection attempt failed ... (os error 10060)

💡 Suggested Optimizations
To effectively utilize parallel deployments and resolve these bottlenecks, I suggest the following refactorings:

1. "Fail-Fast" Dispatcher & Timeout Logic
Waiting 21 seconds for a batch to fail is unacceptable for real-time traffic.

Proposal: Implement a configurable request_timeout (e.g., 5-8 seconds). If a request to a specific GAS Deployment ID exceeds this limit, the client should treat it as a failure, mark that deployment as "temporarily degraded," and offload the batch to the next available deployment immediately.

2. Deployment Health-Scoring System
With 7 deployments in use, the client needs better awareness of backend health.

Proposal: Introduce a simple scoring or weight system for the Deployment ID list. If a deployment triggers a timeout, it should be penalized (cooldown period) and removed from the rotation for a few minutes. This prevents the client from repeatedly hitting a throttled or slow account.

3. Optimized Flush Interval (Batch Muxer)
Proposal: The current batching logic appears to be too conservative, contributing to unnecessary latency. Please make max_batch_size and flush_interval tunable parameters. For mode: full, we need a more aggressive flush strategy to ensure that traffic is not unnecessarily queued when RTT is high.

4. Persistent Connection Pooling
Proposal: Ensure that the Rust HTTP client (using reqwest or hyper) is configured to maintain keep-alive connections to all 7 GAS endpoints. Currently, if the client performs a new TLS handshake for every batch request across 7 accounts, the overhead is massive. Maintaining persistent TCP tunnels to each Google front-end is critical for performance.

🏁 Conclusion
The current multi-account setup shows great potential, but the client-side dispatching logic is holding it back by treating all endpoints as equally reliable regardless of their real-time performance. Implementing these changes will transform mode: full into a much more stable and responsive tunneling solution.

I am highly motivated to help test these changes. Please let me know if you are open to a PR or need further debugging information.

please look at the issue and if you can helP For performance
@dazzling-no-more @amirabbas117 @therealaleph @claude @vahidlazio @hamed256