mhr-cfw

[mehdisrmd]

Please consider this repo
This is the next step
https://github.com/denuitt1/mhr-cfw

[w0l4i]

Please consider this repo This is the next step https://github.com/denuitt1/mhr-cfw

nice approach but in here a few task's are in list and after that if the main dev approve the idea of mhrv-rst as multi sdk it will be better and faster equivalent of this fork you have been mentioned

[therealaleph]

@mehdisrmd — thanks for the pointer. Took a quick look at denuitt1/mhr-cfw: created yesterday, ~15 stars, Python. Without auditing the code I can't promise anything yet, but a Cloudflare Workers port has been on the roadmap since #313 and #343 — so direction-wise, yes, "next step" is right.

Two paths to integrate:

1. Adopt the existing project as-is — list it in docs/ as a recommended companion, link it from the README, leave it independently maintained. Lowest effort; depends on whether the upstream maintainer is reliable + whether the code is auditable.

2. Port the CF Workers logic into this repo as a cf-workers/ directory alongside tunnel-node/ + assets/apps_script/Code.gs — keeps everything in one place, audit surface is smaller, but more work upfront.

I'll review denuitt1/mhr-cfw over the next day or two:

• Audit the worker.js / Python tooling for the bootstrap
• Compare protocol against our Apps Script Code.gs — if they're protocol-compatible (same {"k":"...","q":[...]} shape), our existing Rust client could switch backends just by changing connect_host + front_domain. If not, client needs a new code path.
• Check if it handles the same set of features (batch ops, streaming, gzip, etc.)

If audit clears, will write up findings + a path to ship. If there are gaps, will document them in a fresh issue.

For users right now: Apps Script-based mhrv-rs continues to be the recommended path. CF Workers as alternative is "experimental" until I've reviewed mhr-cfw or shipped our own port.

Tracking this in the v1.8.x / v1.9.x roadmap. Will report back on the audit.

---

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

[Plangto]

Please consider this repo This is the next step https://github.com/denuitt1/mhr-cfw

Does this fix cloudflare js challenge on sites that are protected which cloudflare? Or captcha

[therealaleph]

@Plangto — short answer: no, mhr-cfw doesn't fix the Cloudflare JS challenge / captcha problem. Walking through why:

The Cloudflare anti-bot challenge is not at the relay layer.

When you visit https://x.com (Cloudflare-protected) via mhrv-rs, the chain is:

your browser → mhrv-rs → Apps Script → Cloudflare's edge → x.com origin
                                          ▲
                                     anti-bot lives here

Cloudflare's edge (where x.com is hosted) sees the inbound TLS connection's source IP and runs heuristics on it — datacenter-IP detection, JA3 fingerprint, request-rate, etc. If the source IP looks like a bot/datacenter, Cloudflare presents Turnstile / JS challenge / captcha.

Switching the relay backend from Apps Script to CF Workers (which is what mhr-cfw would do) changes the chain to:

your browser → mhrv-rs → CF Workers → Cloudflare's edge → x.com origin
                              ▲             ▲
                  worker IP space      anti-bot still here

The destination's anti-bot still runs. Cloudflare's edge sees the request now coming from a Cloudflare Workers IP — which is inside Cloudflare's own network. Cloudflare can fingerprint this trivially as "internal worker request" and apply different rules (often stricter, since Workers are commonly used for scraping by abuse actors).

In practice, switching from Apps Script-relay to CF-Workers-relay either gives you the same captcha problem, or a worse version of it. Neither relay infrastructure can hide that the request is coming from a server, not a residential browser.

What actually fixes Cloudflare anti-bot:

1. Residential IP outbound — the only reliable path. Options:

   • Run tunnel-node on a residential connection (a VPS at a friend's house, a cheap residential proxy provider)
   • Run tunnel-node on a regular VPS + chain WARP for the outbound (Feature Request: Support Cloudflare WARP as an Outbound for Geo-blocking and Captcha Mitigation #309 — coming v1.8.x with --upstream-interface warp)
   • Use a residential proxy service as the upstream (rotating residential IPs that look like real ISPs)

2. Browser fingerprint mimicry — make the request look exactly like a real Chrome/Firefox/Safari from a real user. Hard to do well, requires JA3 fingerprint matching + correct TLS extension order + browser-specific User-Agent etc. mhrv-rs partially does this with the v1.8.0 random padding, but full Chrome-mimicry is a major v1.9.x or later feature.

3. passthrough_hosts for the specific site — bypass mhrv-rs entirely for that site. Means your real ISP IP hits Cloudflare, which (if you're a real human) passes the anti-bot heuristic. Trade-off: your real IP visible to that site (privacy), and the path may be ISP-filtered.

Practical recommendation for users hit by CF anti-bot on commonly-protected sites (Twitter/X, GitHub auth, Discord, OpenAI, etc.):

• Best: Full mode + VPS + WARP outbound (when shipped). Cloudflare sees a residential-ish IP via Cloudflare's own consumer proxy.
• Now: passthrough_hosts: ["x.com", "github.com"] + accept your real IP being visible to those sites. Most users in censored regions don't have a real-IP-filtering problem on large CF-protected sites — those sites are usually accessible direct, just slow or unreliable.
• Future: when v1.9.x ships TLS fingerprint randomization ([RFC] Roadmap to v1.9: xmux-style Stream Splitting, Temporal Jitter, and Resilience against Active Throttling #369 §2 — Chrome-mimicry), the JA3 axis improves but the IP axis still requires residential outbound.

For the original mhr-cfw question: worth tracking as alternative relay backend for users where Apps Script outbound is more filtered than Cloudflare Workers (#313 scenario), but not a Cloudflare-anti-bot fix. Different problem.

This is a useful clarifying question — I'll lift the explanation into the FAQ docs that @kanan-droid is starting in #333. The "why doesn't anything fix Cloudflare captcha" answer keeps coming up in this issue tracker.

---

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

[Plangto]

@Plangto — short answer: no, mhr-cfw doesn't fix the Cloudflare JS challenge / captcha problem. Walking through why:

The Cloudflare anti-bot challenge is not at the relay layer.

When you visit https://x.com (Cloudflare-protected) via mhrv-rs, the chain is:

your browser → mhrv-rs → Apps Script → Cloudflare's edge → x.com origin
                                          ▲
                                     anti-bot lives here

Cloudflare's edge (where x.com is hosted) sees the inbound TLS connection's source IP and runs heuristics on it — datacenter-IP detection, JA3 fingerprint, request-rate, etc. If the source IP looks like a bot/datacenter, Cloudflare presents Turnstile / JS challenge / captcha.

Switching the relay backend from Apps Script to CF Workers (which is what mhr-cfw would do) changes the chain to:

your browser → mhrv-rs → CF Workers → Cloudflare's edge → x.com origin
                              ▲             ▲
                  worker IP space      anti-bot still here

The destination's anti-bot still runs. Cloudflare's edge sees the request now coming from a Cloudflare Workers IP — which is inside Cloudflare's own network. Cloudflare can fingerprint this trivially as "internal worker request" and apply different rules (often stricter, since Workers are commonly used for scraping by abuse actors).

In practice, switching from Apps Script-relay to CF-Workers-relay either gives you the same captcha problem, or a worse version of it. Neither relay infrastructure can hide that the request is coming from a server, not a residential browser.

What actually fixes Cloudflare anti-bot:

1. Residential IP outbound — the only reliable path. Options:

   • Run tunnel-node on a residential connection (a VPS at a friend's house, a cheap residential proxy provider)
   • Run tunnel-node on a regular VPS + chain WARP for the outbound (Feature Request: Support Cloudflare WARP as an Outbound for Geo-blocking and Captcha Mitigation #309 — coming v1.8.x with --upstream-interface warp)
   • Use a residential proxy service as the upstream (rotating residential IPs that look like real ISPs)

2. Browser fingerprint mimicry — make the request look exactly like a real Chrome/Firefox/Safari from a real user. Hard to do well, requires JA3 fingerprint matching + correct TLS extension order + browser-specific User-Agent etc. mhrv-rs partially does this with the v1.8.0 random padding, but full Chrome-mimicry is a major v1.9.x or later feature.

3. passthrough_hosts for the specific site — bypass mhrv-rs entirely for that site. Means your real ISP IP hits Cloudflare, which (if you're a real human) passes the anti-bot heuristic. Trade-off: your real IP visible to that site (privacy), and the path may be ISP-filtered.

Practical recommendation for users hit by CF anti-bot on commonly-protected sites (Twitter/X, GitHub auth, Discord, OpenAI, etc.):

• Best: Full mode + VPS + WARP outbound (when shipped). Cloudflare sees a residential-ish IP via Cloudflare's own consumer proxy.
• Now: passthrough_hosts: ["x.com", "github.com"] + accept your real IP being visible to those sites. Most users in censored regions don't have a real-IP-filtering problem on large CF-protected sites — those sites are usually accessible direct, just slow or unreliable.
• Future: when v1.9.x ships TLS fingerprint randomization ([RFC] Roadmap to v1.9: xmux-style Stream Splitting, Temporal Jitter, and Resilience against Active Throttling #369 §2 — Chrome-mimicry), the JA3 axis improves but the IP axis still requires residential outbound.

For the original mhr-cfw question: worth tracking as alternative relay backend for users where Apps Script outbound is more filtered than Cloudflare Workers (#313 scenario), but not a Cloudflare-anti-bot fix. Different problem.

This is a useful clarifying question — I'll lift the explanation into the FAQ docs that @kanan-droid is starting in #333. The "why doesn't anything fix Cloudflare captcha" answer keeps coming up in this issue tracker.

[reply via Anthropic Claude | reviewed by @therealaleph]

So Basically its useless changing from GAS to GAS + CF worker at least its currently useless right?

[kanan-droid]

@Plangto — short answer: no, mhr-cfw doesn't fix the Cloudflare JS challenge / captcha problem. Walking through why:

The Cloudflare anti-bot challenge is not at the relay layer.

When you visit https://x.com (Cloudflare-protected) via mhrv-rs, the chain is:

your browser → mhrv-rs → Apps Script → Cloudflare's edge → x.com origin
                                          ▲
                                     anti-bot lives here

Cloudflare's edge (where x.com is hosted) sees the inbound TLS connection's source IP and runs heuristics on it — datacenter-IP detection, JA3 fingerprint, request-rate, etc. If the source IP looks like a bot/datacenter, Cloudflare presents Turnstile / JS challenge / captcha.

Switching the relay backend from Apps Script to CF Workers (which is what mhr-cfw would do) changes the chain to:

your browser → mhrv-rs → CF Workers → Cloudflare's edge → x.com origin
                              ▲             ▲
                  worker IP space      anti-bot still here

The destination's anti-bot still runs. Cloudflare's edge sees the request now coming from a Cloudflare Workers IP — which is inside Cloudflare's own network. Cloudflare can fingerprint this trivially as "internal worker request" and apply different rules (often stricter, since Workers are commonly used for scraping by abuse actors).

In practice, switching from Apps Script-relay to CF-Workers-relay either gives you the same captcha problem, or a worse version of it. Neither relay infrastructure can hide that the request is coming from a server, not a residential browser.

What actually fixes Cloudflare anti-bot:

1. Residential IP outbound — the only reliable path. Options:

   • Run tunnel-node on a residential connection (a VPS at a friend's house, a cheap residential proxy provider)
   • Run tunnel-node on a regular VPS + chain WARP for the outbound (Feature Request: Support Cloudflare WARP as an Outbound for Geo-blocking and Captcha Mitigation #309 — coming v1.8.x with --upstream-interface warp)
   • Use a residential proxy service as the upstream (rotating residential IPs that look like real ISPs)

2. Browser fingerprint mimicry — make the request look exactly like a real Chrome/Firefox/Safari from a real user. Hard to do well, requires JA3 fingerprint matching + correct TLS extension order + browser-specific User-Agent etc. mhrv-rs partially does this with the v1.8.0 random padding, but full Chrome-mimicry is a major v1.9.x or later feature.

3. passthrough_hosts for the specific site — bypass mhrv-rs entirely for that site. Means your real ISP IP hits Cloudflare, which (if you're a real human) passes the anti-bot heuristic. Trade-off: your real IP visible to that site (privacy), and the path may be ISP-filtered.

Practical recommendation for users hit by CF anti-bot on commonly-protected sites (Twitter/X, GitHub auth, Discord, OpenAI, etc.):

• Best: Full mode + VPS + WARP outbound (when shipped). Cloudflare sees a residential-ish IP via Cloudflare's own consumer proxy.
• Now: passthrough_hosts: ["x.com", "github.com"] + accept your real IP being visible to those sites. Most users in censored regions don't have a real-IP-filtering problem on large CF-protected sites — those sites are usually accessible direct, just slow or unreliable.
• Future: when v1.9.x ships TLS fingerprint randomization ([RFC] Roadmap to v1.9: xmux-style Stream Splitting, Temporal Jitter, and Resilience against Active Throttling #369 §2 — Chrome-mimicry), the JA3 axis improves but the IP axis still requires residential outbound.

For the original mhr-cfw question: worth tracking as alternative relay backend for users where Apps Script outbound is more filtered than Cloudflare Workers (#313 scenario), but not a Cloudflare-anti-bot fix. Different problem.

This is a useful clarifying question — I'll lift the explanation into the FAQ docs that @kanan-droid is starting in #333. The "why doesn't anything fix Cloudflare captcha" answer keeps coming up in this issue tracker.

[reply via Anthropic Claude | reviewed by @therealaleph]

but could it increase speed becuz cloud workers has less limits than google scripts so the client run in tunnel mode it could make messengers faster and even fixes youtube's age restriction problem

[therealaleph]

@kanan-droid — separating the two questions:

Speed — yes, CF Workers would be measurably faster

Comparison of the relevant limits:

Limit	Apps Script	CF Workers (free)
Per-call latency floor	~250-500ms (Google internal hop)	~10-50ms (edge POPs)
Per-account daily quota	20k fetches/day	100k req/day
Concurrent executions	30/account hard cap	No hard cap (auto-scales)
Per-request CPU	6 min wall	10ms CPU / 30s wall
Per-response size	50 MB	25 MB

For mhrv-rs's workload (light JSON parsing + HTTP forwarding), the CF Workers' 10ms CPU budget is enough — we're not doing heavy compute, just relaying bytes. The 30s wall is the constraint, but typical batch responses come back in 1-2s.

Real-world impact for browsing:

• Per-flow throughput ceiling rises from chunk_bytes / (250-500ms) ≈ 50-200 KB/s to chunk_bytes / (50ms) ≈ 500 KB/s - 2 MB/s
• Telegram realtime chat (small frequent messages): each round-trip drops from ~500ms to ~100ms perceived latency = noticeably snappier
• YouTube short videos: SABR cliff still hits at ~30s (CF Workers' wall), better than 60s but not unlimited
• Concurrency ceiling effectively gone — could do 100+ parallel flows where Apps Script tops out at 30

Trade-off: SABR cliff actually gets WORSE. Apps Script's 6-min execution lets a single long-poll fetch carry 60s of streaming before failing; CF Workers' 30s wall makes that 30s. So YouTube long-form videos break sooner on CF Workers. Mitigated by chunked re-requests but adds complexity.

Net: CF Workers faster for general browsing, similar or worse for YouTube streaming. The right choice depends on workload.

YouTube age restriction — no, CF Workers won't fix it

Age restriction is a server-side check at YouTube/Google, based on the signed-in Google account's age verification status (or the lack of a session → conservative default → restriction shown).

The relay (Apps Script or CF Workers) doesn't carry your YouTube account session — it's making an anonymous outbound request. Both relays look identical to YouTube's age-check engine: anonymous request → restriction.

The fix is sign-in, not relay choice:

• Sign into YouTube with a Google account that's age-verified (linked phone number with confirmed birth-date over 18)
• The session cookie + auth headers travel with each request through the relay
• YouTube sees the verified session → no restriction

Apps Script + CF Workers + tunnel-node + direct connection all give the same outcome on this axis. It's an account-level YouTube property, not a transport property.

Practical note: if you want anonymous-but-unrestricted YouTube, it's unfortunately not architecturally available — YouTube specifically uses anonymous-default-restrict to push users toward signing in.

---

For the original mhr-cfw evaluation: speed gains are real, age-restriction unaffected, SABR cliff slightly worse. Net positive for Telegram + browsing-heavy use, neutral-to-negative for YouTube long-form. Worth shipping as alternative backend for the right workload, not a universal upgrade.

This is a great "would X fix Y" question that benefits from being explicit about which axis matters. I'll add this comparison table to the FAQ once it's structured.

---

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