denuitt1/mhr-cfwUn relais de Domain-Fronting qui achemine le trafic via GAS (Google Apps Script) et le transmet aux Workers Cloudflare. Conçu pour contourner le DPI.
Client -> Relais local -> Google/CDN Front -> Relais GAS (Google Apps Script) -> Cloudflare Worker -> Sortie
|
+-> Affiche www.google.com au filtre DPI du réseau
Client -> Relais local -> Google/CDN Front -> Relais GAS (Google Apps Script) -> Cloudflare Worker -> Relais amont auto-hébergé -> Sortie
|
+-> Affiche www.google.com au filtre DPI du réseau
En utilisation normale, le navigateur envoie le trafic au proxy exécuté sur votre ordinateur.
Le proxy transmet ce trafic via l’infrastructure de Google afin que le réseau ne voie qu’un domaine autorisé tel que www.google.com.
Votre relais déployé récupère ensuite le site réel via le worker Cloudflare et renvoie la réponse par le même chemin.
Ainsi, le filtre voit un trafic Google normal, tandis que la destination réelle reste cachée dans la requête du relais.
git clone https://github.com/denuitt1/mhr-cfw.git
cd mhr-cfw
pip install -r requirements.txt
Impossible d’accéder directement à PyPI ? Utilisez ce miroir à la place :
pip install -r requirements.txt -i https://mirror-pypi.runflare.com/simple/ --trusted-host mirror-pypi.runflare.com
worker.js de ce projet (dans deploy/), copiez tout, et collez-le dans l’éditeur Apps Script.const WORKER_URL = "myworker.workers.dev";
Code.gs de ce projet (dans deploy/), copiez tout, et collez-le dans l’éditeur Apps Script.const AUTH_KEY = "votre-mot-de-passe-secret-ici";
const WORKER_URL = "https://myworker.workers.dev";
⚠️ Souvenez-vous du mot de passe que vous avez défini à l’étape 3. Vous utiliserez le même mot de passe dans le fichier de configuration ci-dessous.
Cliquez sur le fichier run.bat (sous Windows) ou run.sh (sous Linux) pour démarrer le relais.
Si vous l’exécutez pour la première fois, un assistant de configuration vous demandera de saisir la clé AUTH_KEY et l’ID de déploiement de Google Apps Script.
Vous devriez voir un message indiquant que le proxy HTTP est en cours d’exécution sur 127.0.0.1:8085.
Nous recommandons d’utiliser le client v2rayN et de configurer un proxy socks5.
Vous pouvez également utiliser l’extension FoxyProxy pour Chrome ou Firefox pour utiliser ce proxy dans votre navigateur.
Ouvrez ipleak.net dans votre navigateur. Vous devriez voir votre adresse IP définie sur celle de Cloudflare.
Lorsque vous exécutez une machine virtuelle (VM), elle opère dans un environnement réseau isolé, séparé de l’hôte. Par défaut, la VM ne peut pas accéder directement aux services tournant sur localhost de la machine hôte — y compris ce proxy.
Pour résoudre ce problème, vous devez trouver l’adresse IP de la passerelle que votre hyperviseur attribue à l’hôte, puis l’utiliser à la place de localhost lors de la configuration du proxy à l’intérieur de la VM.
Exemple : VirtualBox (mode NAT)
L’hôte est toujours accessible depuis la VM à l’adresse 10.0.2.2. Configurez le proxy :
export http_proxy="http://10.0.2.2:8085"
export https_proxy="http://10.0.2.2:8085"
export all_proxy="socks5://10.0.2.2:8085"
Pour rendre cela permanent, ajoutez les lignes ci-dessus à ~/.bashrc et exécutez source ~/.bashrc.
Étant donné que ce proxy effectue une inspection SSL, vous pourriez voir des erreurs de certificat. Installez le fichier ca.crt inclus pour les résoudre :
sudo cp ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates
Vous pouvez utiliser ce proxy sur votre téléphone ou tout autre appareil du même réseau — aucun logiciel supplémentaire nécessaire.
1. Trouver l’IP de votre hôte
# Windows
ipconfig
# Linux / macOS
ip addr
Cherchez l’IP de l’interface connectée à votre routeur (ex. 192.168.1.8).
2. Rediriger le port (Windows uniquement, si le service est lié à localhost)
Exécutez CMD en tant qu’administrateur :
netsh interface portproxy add v4tov4 listenaddress=192.168.1.8 listenport=8085 connectaddress=127.0.0.1 connectport=8085
netsh advfirewall firewall add rule name="Proxy 8085" dir=in action=allow protocol=TCP localport=8085
3. Configurer le proxy sur votre téléphone
Connectez votre téléphone au même Wi-Fi, puis configurez le proxy manuellement :
192.168.1.8)8085Sur Android : Paramètres → Wi-Fi → Modifier → Proxy → Manuel
Sur iPhone : Paramètres → Wi-Fi → (réseau) → Proxy HTTP → Manuel
4. Installer le certificat CA
Transférez ca.crt sur votre téléphone, puis :
Les CAPTCHAs (Cloudflare Turnstile/défi bot, reCAPTCHA, hCaptcha) lient les jetons
à l’IP qui a résolu le défi. Les Workers Cloudflare sortent par différentes
IP de bordure selon les requêtes, donc la vérification sur le site cible échoue même si
vous résolvez le défi. Ce module optionnel fait que le Worker transmet tous les appels fetch()
via un petit serveur Node que vous exécutez sur un VPS avec une IP stable — offrant
au site cible une seule adresse de sortie cohérente.
cf_clearance).Si vous ne rencontrez pas ces problèmes, laissez-le non configuré — le Worker se comporte exactement comme avant.
Les Workers Cloudflare n’exposent pas d’IP de sortie stable — fetch() sort via un pool rotatif d’IP de bordure Cloudflare, ce qui casse exactement les jetons CAPTCHA liés à une IP. Les options d’égress statique de Cloudflare (BYOIP, Egress Workers) sont réservées aux abonnements Entreprise, donc un petit VPS avec une IP statique est la solution pratique. Le relais amont est simplement un proxy léger qui réexécute le fetch() depuis une adresse stable.
L’implémentation de référence est deploy/upstream-forwarder/upstream_forwarder.js.
Il nécessite Node 18+ et aucune dépendance. Exécutez-le derrière Caddy ou nginx avec TLS — le Worker rejette les URLs de relais amont non-HTTPS.
# Sur votre VPS (exemple Ubuntu/Debian) :
sudo apt install -y nodejs # doit être 18+
export AUTH_KEY="une-chaine-longue-aleatoire-d-au-moins-32-caracteres"
export PORT=8787
node deploy/upstream-forwarder/upstream_forwarder.js
Frontal avec Caddy pour le TLS automatique :
forwarder.example.com {
reverse_proxy 127.0.0.1:8787
}
Test rapide :
curl -X POST https://forwarder.example.com/fwd \
-H "x-upstream-auth: $AUTH_KEY" \
-H "content-type: application/json" \
-d '{"u":"https://httpbin.org/ip","m":"GET","h":{}}'
Le corps de la réponse décodée devrait afficher l’IP du VPS.
Dans le tableau de bord Cloudflare → votre Worker → Paramètres → Variables et secrets :
Enregistrez et redéployez le Worker.
Naviguez vers https://httpbin.org/ip via le proxy — vous devriez voir l’IP du VPS, pas celle de Cloudflare. Ensuite, revisitez un site protégé par CAPTCHA qui ne fonctionnait pas — le défi devrait maintenant être validé.
Le relais amont doit nécessiter une authentification. Sans
AUTH_KEY, il refuse de démarrer. Toute personne possédant l’URL et la clé peut l’utiliser comme relais, donc gardez les deux secrets.
Par défaut, chaque requête traitée par le Worker passe par le relais amont, ce qui consomme la bande passante du VPS même pour du trafic non concerné. Pour n’envoyer que les sites nécessitant une IP de sortie stable via le VPS, listez-les dans forwarder_hosts dans config.json — même syntaxe que bypass_hosts (nom d’hôte exact ou .suffixe). Tout ce qui n’est pas correspondant revient au fetch() direct sur le Worker.
{
...
"forwarder_hosts": [
"example.com",
".cf-protected-suffix"
]
...
}
Laissez la liste vide (ou supprimez la clé) pour conserver le comportement historique « tout transférer ».
MHR-CFW est fourni à des fins éducatives, de test et de recherche uniquement.
| Nom | Type | Valeur |
|---|
UPSTREAM_FORWARDER_URL | Secret | https://forwarder.example.com/fwd |
UPSTREAM_AUTH_KEY | Secret | le même AUTH_KEY que vous avez défini sur le VPS |
UPSTREAM_FAIL_MODE | Variable | closed (par défaut) — renvoie 502 en cas d’échec du relais amont. Utilisez open pour revenir au fetch direct. |
UPSTREAM_TIMEOUT_MS | Variable (optionnel) | par défaut 25000 |