---
title: "Node Unblocker: qué es y cómo configurarlo de forma segura"
description: "Node Unblocker es un middleware de Express que convierte un servidor Node.js en un proxy web que reescribe URL. Cómo funciona, código probado y cómo protegerlo."
url: https://proxynet.io/es/blog/node-unblocker
date: 2026-10-11
author: "Acar Diveroli"
category: "Tutoriales, Proxy 101"
lang: es
---

# Node Unblocker: qué es y cómo configurarlo de forma segura

Arrancas una pequeña app de Express, abres `http://127.0.0.1:8080/proxy/https://example.com/` en el navegador y la página aparece bajo la dirección de tu propio servidor. Sus enlaces, imágenes y formularios empiezan ahora por `/proxy/`, así que cada clic vuelve a pasar por tu servidor. Eso es Node Unblocker, el paquete `unblocker` de npm: unas pocas líneas que convierten un servidor Node.js en un proxy web que cualquiera puede usar con un navegador normal. Si lo dejas abierto, esas mismas líneas permiten que también lo usen desconocidos; nuestra primera instancia de prueba descargó una página de administración que un servicio local solo mostraba a `127.0.0.1`.

Este artículo explica cómo funciona y muestra un servidor mínimo, uno reforzado que deja fuera a desconocidos y direcciones internas, un proxy upstream para el tráfico saliente y los límites del paquete. Todos los ejemplos se ejecutaron el 11 de octubre de 2026 con unblocker 2.3.1, Express 4.22.3 y Node.js 24.11.1, contra un sitio de prueba local, un servidor de eco WebSocket y un proxy de prueba que exige usuario y contraseña.

> **Nota: Respuesta breve**
>
> Node Unblocker (`unblocker` en npm) es un middleware compatible con Express que convierte un servidor Node.js en un proxy web. Un visitante abre `/proxy/https://site.example/`, el servidor descarga la página, reescribe sus enlaces, cookies y redirecciones para que apunten de nuevo a `/proxy/` y la transmite al navegador. El sitio ve la IP de tu servidor, no la del visitante. Nunca lo publiques en internet sin un login, una lista de sitios permitidos y un bloqueo de las direcciones privadas, o cualquiera podrá enviar su tráfico a través de tu servidor.

## ¿Qué es Node Unblocker?

Node Unblocker es una biblioteca de código abierto para Node.js creada por Nathan Friedly y publicada en npm como `unblocker`. El 11 de octubre de 2026 la última versión era la 2.3.1, de junio de 2024; necesita Node.js 16.17 o posterior y tiene licencia AGPL-3.0. Su [README en GitHub](https://github.com/nfriedly/node-unblocker) la describe como una biblioteca de uso general para cargar páginas web remotas a través de un proxy y reescribirlas.

Es un proxy web: un sitio web que carga otros sitios por ti. El visitante no cambia ningún ajuste y solo necesita la dirección de tu servidor. Un proxy HTTP o SOCKS5, en cambio, se configura en una app o en el sistema operativo y deja pasar el tráfico sin modificarlo. Node Unblocker solo maneja páginas web y WebSockets, y tiene una única salida: la IP de la máquina en la que se ejecuta. Si lo ejecutas en tu propio equipo, el sitio ve la IP de tu conexión doméstica.

## ¿Cómo funciona Node Unblocker?

Cada petición cuya ruta empieza por el prefijo (`/proxy/` por defecto) pasa por estos pasos:

1. **El navegador pide una URL del proxy**, como `GET /proxy/https://example.com/`. Todo lo que va después del prefijo es el destino. Una URL sin esquema, como `/proxy/example.com`, recibe un `307` hacia `/proxy/http://example.com/`.
2. **Se ejecuta el middleware de petición.** Unas funciones integradas corrigen las cabeceras `Host` y `Referer`, la compresión y las cookies. Después se ejecutan tus propias funciones de `requestMiddleware`; los controles de acceso van aquí.
3. **Tu servidor se conecta al destino** con las cabeceras del navegador, a través de `httpAgent` o `httpsAgent` si has definido uno. El destino ve la IP de tu servidor.
4. **El middleware de respuesta edita la respuesta.** Elimina las cabeceras `Content-Security-Policy`, `Strict-Transport-Security` y `Public-Key-Pins`, reescribe las redirecciones y las URL del HTML y el CSS, mueve las cookies a la ruta `/proxy/<site>/`, inyecta un script y añade una etiqueta robots `NOINDEX, NOFOLLOW`.
5. **La página vuelve en streaming**, fragmento a fragmento.
6. **Se recuperan los enlaces que se escapan.** Una petición relativa a la raíz, como `/about`, llega sin el prefijo; Node Unblocker lee el `Referer` y responde con un `307` hacia la URL completa del proxy.

El script inyectado envuelve `fetch`, `XMLHttpRequest`, WebSocket, los elementos nuevos y los cambios del historial, de modo que las direcciones que construye JavaScript también reciben el prefijo. Los archivos JavaScript en sí no se reescriben. Nuestra página de prueba, con un enlace absoluto, uno relativo a la raíz y uno relativo, una imagen con URL relativa al protocolo y un formulario, volvió así:

```text
set-cookie: session=abc123; Path=/proxy/http://127.0.0.1:9000/; HttpOnly

<script src="/proxy/client/unblocker-client.js"></script>
<script>unblockerInit({"prefix":"/proxy/","url":"http://127.0.0.1:9000/"}, window);</script>
<title>Test page</title><meta name="ROBOTS" content="NOINDEX, NOFOLLOW"/>
<a href="/proxy/https://www.iana.org/help/example-domains">absolute</a>
<a href="/proxy/http://127.0.0.1:9000/about">root-relative</a>
<a href="contact">relative</a>
<img src="/proxy/http://cdn.example.net/logo.png">
<form action="/proxy/http://127.0.0.1:9000/login" method="post"></form>
```

El enlace relativo ya se resuelve dentro de la ruta del proxy, así que se queda igual. Las cabeceras `Content-Security-Policy` y `Strict-Transport-Security` de la página nunca llegaron al navegador.

## ¿En qué se diferencia de un forward proxy o un proxy inverso?

Los tres se colocan entre un navegador y un sitio. Se diferencian en quién los configura y en si modifican la página.

| | Node Unblocker | Forward proxy | Proxy inverso |
|---|---|---|---|
| Cómo se usa | Abrir una URL `/proxy/` | Poner host:port en la app o el sistema | Visitar la dirección propia del sitio |
| Quién lo configura | Quien gestiona el servidor | El usuario o su empresa | El propietario del sitio |
| Modifica la página | Sí: enlaces, cookies, redirecciones | No | Normalmente no |
| HTTPS | Se descifra en tu servidor | Va por un túnel, sigue cifrado | Lo descifra el propietario del sitio |
| Tráfico | Páginas web y WebSockets | Cualquier HTTP; SOCKS5 también UDP | HTTP(S) hacia los servidores del sitio |

Un forward proxy sirve a cualquier app que tenga un ajuste de proxy y nunca necesita entender la página. Un proxy inverso (reverse proxy) como nginx se coloca delante de tu propio sitio; [Forward proxy y reverse proxy: ¿en qué se diferencian?](/es/blog/forward-vs-reverse-proxy) explica los dos. Node Unblocker es el caso aparte: un proxy que reescribe páginas para navegadores cuyos ajustes no se pueden o no se deben cambiar.

## ¿Cómo se configura un servidor mínimo de Node Unblocker?

En una carpeta vacía, instala Express y el paquete, y guarda después el código como `server.mjs`:

```bash
npm install express unblocker
```

```js
import express from "express";
import Unblocker from "unblocker";

const app = express();
const unblocker = new Unblocker({ prefix: "/proxy/" });

// Unblocker tiene que ser una de las primeras llamadas a app.use() y debe ir en la raíz, no en una subruta
app.use(unblocker);

app.get("/", (req, res) => res.send("Open /proxy/https://example.com/"));

// El listener de upgrade permite que Unblocker retransmita las conexiones WebSocket
app.listen(8080, "127.0.0.1").on("upgrade", unblocker.onUpgrade);
```

Ejecuta `node server.mjs` y abre `http://127.0.0.1:8080/proxy/https://example.com/`. El README indica que el middleware no debe montarse en una subruta y advierte de que usar `/` como prefijo provoca casos límite. Sin el listener de `upgrade`, los chats y los paneles en vivo de las páginas que pasan por el proxy no pueden conectarse.

El servidor escucha en `127.0.0.1`, así que solo tu equipo puede llegar a él; mantenlo así. En nuestra prueba cargó páginas, reescribió una redirección `302`, reenvió un `POST` de formulario y devolvió los mensajes WebSocket del servidor de eco. También descargó `/proxy/http://127.0.0.1:9000/admin`, una página que nuestro servicio de prueba solo muestra a la propia máquina:

```text
INTERNAL ADMIN PAGE - only for 127.0.0.1
```

**Express 5.** El paquete depende de Express 4, así que repetimos la prueba con Express 5.3.0. Las páginas, las redirecciones, los formularios y los WebSockets funcionaron igual; npm colocó una copia privada de Express 4 dentro del paquete.

## ¿Por qué es peligroso un servidor de Node Unblocker abierto?

Un servidor abierto permite que cualquiera envíe tráfico desde tu IP y llegue a lugares a los que solo llega tu servidor:

- **Tu IP carga con la culpa.** El spam de formularios y los intentos de login por fuerza bruta que pasan por él salen de tu dirección. Los sitios la bloquean o se quejan a tu proveedor de hosting, que puede suspender el servidor.
- **Tu red interna queda al alcance.** Es la falsificación de peticiones del lado del servidor (SSRF): alguien de fuera hace que tu servidor pida una dirección a la que esa persona no puede llegar por sí misma. En un servidor en la nube, el objetivo clásico es `169.254.169.254`, donde el servicio de metadatos entrega credenciales. La [OWASP SSRF Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) recomienda una lista de destinos permitidos y comprobar la IP a la que se resuelve cada nombre.
- **El servidor lo lee todo.** HTTPS termina en tu servidor, porque tiene que leer las páginas para reescribirlas, así que las contraseñas que se escriben en los sitios que pasan por el proxy lo atraviesan en texto claro.
- **Todos los sitios comparten el mismo origen.** Los sitios que pasan por el proxy solo se separan por la ruta de las cookies, y [MDN advierte](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie) de que `Path` no es una medida de seguridad. Un script de una de esas páginas puede leer las cookies de otro sitio que no tengan `HttpOnly`.

Un proxy web tampoco le da a nadie derechos nuevos. Usarlo para esquivar el filtro de un centro educativo o de un lugar de trabajo, o las condiciones de un sitio, sigue incumpliendo esas normas, y el `robots.txt` y los límites de solicitudes de un sitio se aplican a tu servidor como a cualquier otro visitante.

## ¿Cómo se protege un servidor de Node Unblocker?

Trátalo como una herramienta interna para personas concretas y una lista corta de sitios. La versión reforzada añade:

1. **Un login:** un único login HTTP Basic para el equipo, comparado en tiempo constante.
2. **Una lista de hosts permitidos**, solo en los puertos 80 y 443, comprobada en `requestMiddleware`.
3. **Una comprobación de cada respuesta DNS** en el `lookup` de los agentes, porque cualquier dominio puede apuntar a `127.0.0.1`. [`net.BlockList`](https://nodejs.org/api/net.html#class-netblocklist) de Node guarda los rangos privados y también reconoce direcciones IPv4 escritas en formato IPv6.
4. **Limpieza de cabeceras**, para que la cabecera `Authorization` del equipo y la IP del cliente en `X-Forwarded-For` nunca lleguen al sitio.
5. **Una protección para WebSocket**, porque las peticiones de upgrade se saltan el middleware de Express.
6. **Un límite de solicitudes, una línea de log y una página de error sencilla.**

```bash
npm install express unblocker express-rate-limit
```

Después sustituye `server.mjs` por esta versión:

```js
import crypto from "node:crypto";
import dns from "node:dns";
import http from "node:http";
import https from "node:https";
import net from "node:net";
import express from "express";
import { rateLimit } from "express-rate-limit";
import Unblocker from "unblocker";

const { UI_USER, UI_PASS, PORT = "8080" } = process.env;
if (!UI_USER || !UI_PASS) throw new Error("Set UI_USER and UI_PASS");
const ALLOWED = ["example.com", "iana.org"]; // sitios que tu equipo puede abrir (subdominios incluidos)

// 1. Rangos de direcciones a los que el proxy nunca debe conectarse (loopback, privados, link-local, metadatos de la nube)
const blocked = new net.BlockList();
for (const [range, bits] of [["0.0.0.0", 8], ["10.0.0.0", 8], ["100.64.0.0", 10], ["127.0.0.0", 8],
  ["169.254.0.0", 16], ["172.16.0.0", 12], ["192.168.0.0", 16]]) blocked.addSubnet(range, bits);
blocked.addAddress("::1", "ipv6");
blocked.addSubnet("fc00::", 7, "ipv6");
blocked.addSubnet("fe80::", 10, "ipv6");
const isBlockedIp = (ip) => blocked.check(ip, net.isIPv6(ip) ? "ipv6" : "ipv4");

// 2. Comprueba cada respuesta DNS antes de abrir un socket, para que un nombre permitido no apunte dentro de tu red
function safeLookup(hostname, options, callback) {
  dns.lookup(hostname, options, (err, address, family) => {
    if (err) return callback(err);
    const answers = Array.isArray(address) ? address : [{ address, family }];
    if (answers.some((a) => isBlockedIp(a.address))) {
      return callback(new Error(`${hostname} resolves to a blocked address`));
    }
    callback(null, address, family);
  });
}

// 3. Solo hosts de la lista de permitidos en los puertos por defecto 80/443
function isAllowed(target) {
  const { hostname, port } = new URL(target);
  return port === "" && ALLOWED.some((h) => hostname === h || hostname.endsWith(`.${h}`));
}

// Cabeceras que el sitio no debe ver: el login del equipo y la IP del cliente que añade el proxy inverso
const STRIP = ["authorization", "forwarded", "x-forwarded-for", "x-forwarded-host", "x-forwarded-proto", "x-real-ip"];

function checkTarget(data) {
  const ok = isAllowed(data.url);
  console.log(new Date().toISOString(), ok ? "ALLOW" : "DENY", data.url);
  if (ok) {
    for (const h of STRIP) delete data.headers[h];
    return;
  }
  if (data.clientResponse) return data.clientResponse.status(403).send("This site is not on the allowlist.");
  throw new Error("Blocked WebSocket target"); // las peticiones de upgrade no tienen objeto de respuesta
}

// 4. Un login compartido para el equipo (HTTP Basic), comparado en tiempo constante
const hash = (s) => crypto.createHash("sha256").update(s).digest();
function loginOk(req) {
  const [scheme, value = ""] = (req.headers.authorization ?? "").split(" ");
  const given = Buffer.from(value, "base64").toString();
  return scheme === "Basic" && crypto.timingSafeEqual(hash(given), hash(`${UI_USER}:${UI_PASS}`));
}

const unblocker = new Unblocker({
  prefix: "/proxy/",
  requestMiddleware: [checkTarget],
  httpAgent: new http.Agent({ lookup: safeLookup }),
  httpsAgent: new https.Agent({ lookup: safeLookup }),
});

const app = express();
app.set("trust proxy", "loopback"); // el proxy inverso de esta máquina pasa la IP real del cliente
app.use(rateLimit({ windowMs: 60_000, limit: 600 })); // una sola carga de página puede pedir decenas de archivos
app.use((req, res, next) => {
  if (loginOk(req)) return next();
  res.set("WWW-Authenticate", 'Basic realm="preview"').status(401).send("Login required");
});
app.use(unblocker);
app.get("/", (req, res) => res.send("Open /proxy/https://example.com/"));
app.use((err, req, res, next) => {
  console.error(err.message);
  res.status(502).send("The site could not be loaded.");
});

// Escucha solo en loopback: HTTPS y el puerto público son cosa del proxy inverso que va delante
const server = app.listen(Number(PORT), "127.0.0.1");
// El middleware de Express no se ejecuta en los upgrades de WebSocket, así que comprueba el login también aquí
server.on("upgrade", (req, socket, head) => {
  if (!loginOk(req)) return socket.destroy();
  try {
    unblocker.onUpgrade(req, socket, head);
  } catch {
    socket.destroy();
  }
});
```

Arráncalo con el login en variables de entorno: `UI_USER=team UI_PASS='una-clave-larga-y-aleatoria' node server.mjs`. Nuestros resultados:

- Sin el login, todas las rutas devolvieron `401` con una cabecera `WWW-Authenticate: Basic`.
- `example.com` y `www.iana.org` cargaron. `example.org`, `evilexample.com`, `example.com:8443`, `127.0.0.1:9000` y `169.254.169.254` recibieron `403`.
- Con `localtest.me`, un dominio público que se resuelve a `127.0.0.1`, añadido a la lista de permitidos de una copia de prueba, la petición recibió `502` y el log decía `localtest.me resolves to a blocked address`.
- Un WebSocket sin login se cerró. Con login, uno hacia nuestro servidor de eco local quedó registrado como `DENY` y se cerró; uno hacia `echo.websocket.org`, que estaba en la lista de permitidos, funcionó.
- En cuanto llegaron 600 peticiones dentro de un minuto, las siguientes recibieron `429 Too Many Requests` con `Retry-After: 59`.

Dos de estas defensas existen porque la versión obvia falló. El ejemplo de lista de permitidos del README rechaza con `data.clientResponse.status(403)`; un upgrade de WebSocket no tiene objeto de respuesta, así que nuestro servidor se cayó con `TypeError: Cannot read properties of null (reading 'status')`. Con una comprobación de null sobrevivió, pero el WebSocket seguía llegando al destino bloqueado sin login. Lanzar el error y capturarlo en el handler de upgrade lo detiene. Y antes de añadir `STRIP`, nuestro proxy de prueba vio la cabecera `Authorization: Basic` del equipo y un valor de prueba de `X-Forwarded-For` camino del sitio.

Pon HTTPS delante con nginx o Caddy en la misma máquina; `trust proxy` con el valor `loopback` da entonces a Express y al limitador de solicitudes la IP real del cliente. Con nginx, el README recomienda `merge_slashes off;` para que la `//` de `/proxy/https://` se conserve. Guarda las líneas de log `ALLOW` y `DENY`; te permiten responder a un sitio que pregunte qué hizo tu servidor.

## ¿Cómo se envía el tráfico de Node Unblocker por un proxy upstream?

Las opciones `httpAgent` y `httpsAgent` aceptan cualquier agente de Node.js, así que un agente de proxy traslada tu salida al proxy. Instala `http-proxy-agent` y `https-proxy-agent` y sustituye las dos líneas de agentes del servidor reforzado:

```bash
npm install http-proxy-agent https-proxy-agent
```

```js
import { HttpProxyAgent } from "http-proxy-agent";
import { HttpsProxyAgent } from "https-proxy-agent";

const UPSTREAM = process.env.UPSTREAM_PROXY; // http://user:pass@pr.proxynet.io:8000

const unblocker = new Unblocker({
  prefix: "/proxy/",
  requestMiddleware: [checkTarget],
  httpAgent: new HttpProxyAgent(UPSTREAM), // destinos http://: peticiones con URI absoluta al proxy
  httpsAgent: new HttpsProxyAgent(UPSTREAM), // destinos https://: un túnel CONNECT a través del proxy
});
```

Nuestro proxy de prueba pide `user:pass` y registró una línea por destino:

```text
[test-proxy] CONNECT example.com:443 auth=user
[test-proxy] GET http://example.com/ auth=user fwd-authorization=- x-forwarded-for=-
```

La página HTTPS usó un túnel `CONNECT`, así que el proxy solo vio el nombre del host; los guiones muestran que las cabeceras eliminadas se quedaron atrás. Con una contraseña incorrecta, las dos páginas devolvieron el `407 Proxy Authentication Required` del proxy. Codifica `@`, `:` o `/` en la contraseña con `encodeURIComponent`. Los mismos agentes con Axios, node-fetch y undici se explican en [Cómo usar un proxy en Node.js: Axios y node-fetch](/es/blog/nodejs-proxy).

Con un upstream, `safeLookup` deja de ejecutarse, porque el proxy resuelve los nombres en su propia red; por eso, mantén estricta la lista de permitidos. También puedes prescindir de la contraseña: añade la IP pública de tu servidor a la lista de IP autorizadas del panel (hasta 10 direcciones). [Autenticación de proxy: user:pass o lista blanca de IP](/es/blog/proxy-authentication-methods) compara las dos opciones.

Los [Proxies de centro de datos](https://proxynet.io/es/datacenter-proxy) le dan al equipo una IP de salida fija con tráfico sin cuota. Los proxies por IP incluyen acceso a un conjunto de sitios de destino, con el acceso a todos los sitios web como complemento de pago, así que comprueba que los sitios de tu lista de permitidos estén cubiertos.

Para ver una página como la ve un visitante doméstico de otro país, en una revisión de localización, usa los [Proxies residenciales](https://proxynet.io/es/residential-proxy) con una salida elegida por país y ciudad. Una sesión fija de 1 a 60 minutos mantiene la misma salida durante todo un flujo.

## ¿Qué no puede hacer Node Unblocker?

Funciona mejor con páginas normales que se generan sobre todo en el servidor. Sobre el resto, el README es directo:

- **Inicio de sesión con OAuth y `postMessage`.** Es poco probable que funcionen los logins a través de la ventana de otro proveedor.
- **Aplicaciones de una sola página grandes.** El README cita varias plataformas conocidas de chat, vídeo y redes sociales que no funcionan. El script de cliente envuelve las API de peticiones habituales, pero `window.location`, `document.cookie` y `postMessage` siguen en su lista de pendientes.
- **Todo lo que no sea una página web.** Las apps de escritorio, los clientes de correo y las herramientas de línea de comandos necesitan un forward proxy.
- **Mantenimiento lento.** La versión de junio de 2024 seguía siendo la última en octubre de 2026. Los archivos de middleware de `lib/` son cortos; léelos antes de depender del paquete.

## Casos de uso

- Una herramienta interna de vista previa para un equipo de QA o de localización, que abre las páginas de la propia empresa a través de una salida residencial en el país de destino.
- Un quiosco que solo tiene navegador y no puede cambiar sus ajustes de proxy, pero necesita unos pocos sitios aprobados a través de un upstream autenticado.
- Un equipo pequeño que accede al portal de un socio desde una IP fija que el socio ha añadido a su lista de permitidos.
- Aprender cómo funcionan los proxies que reescriben páginas: ejecútalo con `DEBUG=unblocker:*` y observa cada middleware.

En todos los casos: solo sitios que tengas permiso para usar, a un ritmo que el sitio pueda soportar, y nunca como forma de esquivar un filtro o un bloqueo.

## Errores comunes

- **Escuchar en `0.0.0.0` sin login.** El servidor se convierte en un proxy abierto para cualquiera.
- **Comprobar el acceso solo en el middleware de Express.** Los upgrades de WebSocket nunca pasan por él.
- **Usar `data.clientResponse` sin comprobarlo en `requestMiddleware`.** En los upgrades es `null` y tumba el proceso.
- **Fiarse solo de una comprobación del nombre de host.** Comprueba la IP resuelta en el `lookup` del agente.
- **Reenviar todas las cabeceras del navegador.** `Authorization` y `X-Forwarded-For` llegan al destino si no las borras.
- **Mantener la página de error por defecto de Express.** Fuera del modo de producción mostró a nuestro visitante una traza de pila (stack trace) con `getaddrinfo ENOTFOUND`.
- **Iniciar sesión en cuentas personales a través de él.** El servidor ve todas las contraseñas.

## Guía de decisión

| Necesidad | Recomendación |
|---|---|
| Aprender cómo funciona | Servidor mínimo en `127.0.0.1` |
| Un equipo pequeño abre un conjunto fijo de sitios | Servidor reforzado detrás de un proxy inverso con HTTPS |
| Revisar páginas como las ven visitantes de otro país | Servidor reforzado con un upstream residencial |
| Una IP de salida fija que un socio pueda autorizar | Servidor reforzado, con upstream de centro de datos si hace falta |
| Apps, scripts o un navegador completo | Un forward proxy (HTTP o SOCKS5) |
| Logins con OAuth o aplicaciones web grandes | Un navegador normal con un forward proxy |
| Un proxy público para cualquiera | No lo montes |

## Preguntas frecuentes

### ¿Node Unblocker es una VPN?

No. Una VPN lleva todo el tráfico de un dispositivo por un túnel cifrado; Node Unblocker es un sitio web que carga otras páginas por ti. Solo pasa por él lo que abres bajo `/proxy/`, y el servidor lo lee en texto claro.

### ¿Node Unblocker oculta mi dirección IP?

Ante el sitio de destino, sí, si el servidor se ejecuta en otra máquina: el sitio ve la IP del servidor. No te oculta de quien gestiona el servidor, y detrás de un proxy inverso tu IP llega al sitio en `X-Forwarded-For` salvo que se borre esa cabecera.

### ¿Node Unblocker funciona con Express 5?

En nuestra prueba, sí. Con Express 5.3.0, las páginas, las redirecciones, los envíos de formularios y los WebSockets se comportaron igual que con Express 4.22.3; npm instala una copia aparte de Express 4 dentro del paquete.

### ¿Node Unblocker puede hacer de proxy para WebSockets?

Sí, una vez que `unblocker.onUpgrade` está conectado al evento `upgrade` del servidor. Ahí no se ejecuta el middleware de Express, así que comprueba también el login y el destino en ese handler.

### ¿Puedo usar Node Unblocker en un producto comercial?

Sí, bajo la AGPL-3.0: si lo modificas y ofreces la versión modificada a usuarios a través de una red, debes ofrecerles su código fuente. El README indica que el autor también ofrece licencias comerciales.

### ¿Por qué el login funciona pero la página siguiente me cierra la sesión?

Normalmente el sitio pasó de un subdominio a otro o de HTTP a HTTPS. Unblocker guarda las cookies bajo una ruta por sitio y las copia a la nueva ruta con una redirección adicional; su código fuente señala que por el camino se pierden atributos como la caducidad.

## En resumen

Node Unblocker convierte un servidor Express en un proxy web que reescribe páginas para un navegador normal: el visitante abre `/proxy/<url>`, el servidor descarga la página desde su propia IP, reescribe enlaces, cookies y redirecciones y la devuelve en streaming. El servidor mínimo ocupa unas pocas líneas con Express 4 o 5; el trabajo está en hacerlo seguro con un login, una lista de permitidos, la comprobación de la IP resuelta, la limpieza de cabeceras y un handler de WebSocket protegido detrás de HTTPS. Cuando la salida tiene que estar en otro sitio, las opciones de agente envían el tráfico por un upstream, y nuestros [servicios de proxy](/es/proxy) cubren salidas de centro de datos, residenciales, móviles e ISP estáticas.
