denuitt1/mhr-cfwUn Relay de Domain-Fronting que enruta el tráfico a través de GAS (Google Apps Script) y lo reenvía a Cloudflare Workers. Diseñado para evitar DPI.
Client -> Local Relay -> Google/CDN Front -> GAS (Google Apps Script) Relay -> Cloudflare Worker -> Exit
|
+-> Shows www.google.com to network DPI filter
Client -> Local Relay -> Google/CDN Front -> GAS (Google Apps Script) Relay -> Cloudflare Worker -> Self-Hosted Upstream Forwarder -> Exit
|
+-> Shows www.google.com to network DPI filter
En uso normal, el navegador envía el tráfico al proxy que se ejecuta en tu computadora.
El proxy envía ese tráfico a través de la infraestructura de Google para que la red solo vea un dominio permitido como www.google.com.
Tu relay desplegado luego obtiene el sitio web real a través de Cloudflare Worker y envía la respuesta de vuelta por el mismo camino.
Esto significa que el filtro ve tráfico normal de Google, mientras que el destino real permanece oculto dentro de la solicitud del relay.
git clone https://github.com/denuitt1/mhr-cfw.git
cd mhr-cfw
pip install -r requirements.txt
¿No puedes acceder a PyPI directamente? Usa este mirror en su lugar:
pip install -r requirements.txt -i https://mirror-pypi.runflare.com/simple/ --trusted-host mirror-pypi.runflare.com
worker.js de este proyecto (bajo deploy/), copia todo y pégalo en el editor de Apps Script.const WORKER_URL = "myworker.workers.dev";
Code.gs de este proyecto (bajo deploy/), copia todo y pégalo en el editor de Apps Script.const AUTH_KEY = "tu-contraseña-secreta-aqui";
const WORKER_URL = "https://myworker.workers.dev";
⚠️ Recuerda la contraseña que configuraste en el paso 3. Usarás la misma contraseña en el archivo de configuración más abajo.
Haz clic en el archivo run.bat (en Windows) o run.sh (en Linux) para iniciar el relay.
Si es la primera vez que lo ejecutas, se iniciará un asistente de configuración donde deberás ingresar el AUTH_KEY y el ID de implementación de Google Apps Script.
Deberías ver un mensaje indicando que el proxy HTTP se está ejecutando en 127.0.0.1:8085.
Recomendamos usar el cliente v2rayN y configurar un proxy socks5.
También puedes usar la extensión de Chrome o extensión de Firefox de FoxyProxy para usar este proxy en tu navegador.
Abre ipleak.net en tu navegador; deberías ver tu dirección IP establecida como la de Cloudflare.
Cuando ejecutas una máquina virtual (VM), opera en un entorno de red aislado separado del host. Por defecto, la VM no puede acceder directamente a los servicios que se ejecutan en localhost de la máquina host — incluido este proxy.
Para solucionarlo, necesitas encontrar la IP de puerta de enlace que tu hipervisor asigna al host, luego usarla en lugar de localhost al configurar el proxy dentro de la VM.
Ejemplo: VirtualBox (modo NAT)
El host siempre es accesible desde dentro de la VM en 10.0.2.2. Configura el 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"
Para hacer esto permanente, agrega las líneas anteriores a ~/.bashrc y ejecuta source ~/.bashrc.
Dado que este proxy realiza inspección SSL, es posible que veas errores de certificado. Instala el ca.crt incluido para solucionarlos:
sudo cp ca.crt /usr/local/share/ca-certificates/ && sudo update-ca-certificates
Puedes usar este proxy en tu teléfono o cualquier otro dispositivo en la misma red — sin necesidad de software adicional.
1. Encuentra la IP de tu host
# Windows
ipconfig
# Linux / macOS
ip addr
Busca la IP del adaptador conectado a tu router (p. ej., 192.168.1.8).
2. Reenvía el puerto (solo Windows, si el servicio está vinculado a localhost)
Ejecuta CMD como Administrador:
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. Configura el proxy en tu teléfono
Conecta tu teléfono a la misma Wi-Fi, luego configura el proxy manualmente:
192.168.1.8)8085En Android: Ajustes → Wi-Fi → Modificar → Proxy → Manual
En iPhone: Ajustes → Wi-Fi → (red) → Proxy HTTP → Manual
4. Instala el certificado CA
Transfiere ca.crt a tu teléfono, luego:
Los CAPTCHAs (Cloudflare Turnstile/desafío de bot, reCAPTCHA, hCaptcha) vinculan tokens
a la IP que resolvió el desafío. Los Cloudflare Workers salen por diferentes
IPs de borde por solicitud, por lo que la verificación en el sitio de destino falla incluso cuando
resuelves el desafío. Este complemento opcional permite que el Worker envíe todas las llamadas
fetch() a través de un pequeño servidor Node que ejecutas en un VPS con una IP estable — dando
al sitio de destino una dirección de salida consistente.
cf_clearance).Si no te encuentras con esto, déjalo sin configurar — el Worker se comporta exactamente como antes.
Los Cloudflare Workers no exponen una IP de salida estable — fetch() sale a través de un grupo rotatorio de IPs de borde de Cloudflare, que es precisamente lo que rompe los tokens CAPTCHA vinculados a IP. Las opciones de salida estática de Cloudflare (BYOIP, Egress Workers) son de nivel Enterprise, por lo que un VPS pequeño con una IP estática es la solución práctica. El forwarder es solo un proxy ligero que re-emite el fetch() desde una dirección estable.
La implementación de referencia es deploy/upstream-forwarder/upstream_forwarder.js.
Requiere Node 18+ y no tiene dependencias. Ejecútalo detrás de Caddy o nginx con TLS — el Worker rechaza URLs de forwarder que no sean HTTPS.
# En tu VPS (ejemplo Ubuntu/Debian):
sudo apt install -y nodejs # debe ser 18+
export AUTH_KEY="una-cadena-aleatoria-larga-de-al-menos-32-caracteres"
export PORT=8787
node deploy/upstream-forwarder/upstream_forwarder.js
Ponlo detrás de Caddy para TLS automático:
forwarder.example.com {
reverse_proxy 127.0.0.1:8787
}
Prueba rápida:
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":{}}'
El cuerpo de la respuesta decodificada debería mostrar la IP del VPS.
En el panel de Cloudflare → tu Worker → Configuración → Variables y Secretos:
Guarda y vuelve a implementar el Worker.
Navega a https://httpbin.org/ip a través del proxy — deberías ver la IP del VPS, no la de Cloudflare. Luego vuelve a un sitio protegido con CAPTCHA que no funcionaba — el desafío ahora debería validarse.
El forwarder debe requerir autenticación. Sin
AUTH_KEYse niega a iniciar. Cualquier persona con la URL y la clave puede usarlo como relay, así que mantén ambos en secreto.
Por defecto, cada solicitud que maneja el Worker se enruta a través del forwarder, por lo que el tráfico no relacionado también consume ancho de banda del VPS. Para enviar solo los sitios que necesitan una IP de salida estable a través del VPS, enuméralos en forwarder_hosts en config.json — misma sintaxis que bypass_hosts (nombre de host exacto o .sufijo). Cualquier cosa que no coincida vuelve al fetch() directo en el Worker.
{
...
"forwarder_hosts": [
"example.com",
".cf-protected-suffix"
]
...
}
Deja la lista vacía (o elimina la clave) para mantener el comportamiento histórico de "reenviar todo".
MHR-CFW se proporciona únicamente con fines educativos, de prueba e investigación.
| Nombre | Tipo | Valor |
|---|
UPSTREAM_FORWARDER_URL | Secreto | https://forwarder.example.com/fwd |
UPSTREAM_AUTH_KEY | Secreto | el mismo AUTH_KEY que configuraste en el VPS |
UPSTREAM_FAIL_MODE | Variable | closed (predeterminado) — devuelve 502 si falla el forwarder. Usa open para recurrir a fetch directo. |
UPSTREAM_TIMEOUT_MS | Variable (opcional) | predeterminado 25000 |