Cómo montar un puente Tor obfs4 en un VPS

Qué es un puente de Tor y por qué existe

Un puente de Tor es un punto de entrada a la red Tor cuya dirección no se publica en la lista pública de relays. Esa lista, llamada consenso, es un documento firmado que cualquiera puede descargar, incluido un censor. Bloquear Tor a partir de ella lleva una tarde: se descarga el consenso y después se bloquea cada dirección que contiene en el perímetro. Los puentes existen porque la lista publicada es el punto débil. Las direcciones de los puentes se distribuyen de pocas en pocas, de modo que ninguna solicitud entrega el conjunto completo.

Una dirección no incluida en la lista sólo resuelve la mitad del problema. La inspección profunda de paquetes (DPI), que clasifica el tráfico por su contenido en lugar de hacerlo por su dirección, reconoce una conexión Tor por la estructura de su handshake TLS (seguridad de la capa de transporte). Un censor sin la lista aún puede ver que «esto parece Tor» y bloquear la conexión. Un transporte conectable elimina esa señal. En el cliente, envuelve el flujo de Tor en otro protocolo, y el puente lo desenvuelve.

obfs4 es el transporte que utilizan la mayoría de los puentes. Convierte el flujo en bytes sin cabecera ni handshake fijo, por lo que DPI no tiene ningún patrón que identificar. También autentica al cliente. El valor cert= incluido en una línea de puente es una clave que el cliente debe demostrar que posee antes de que el puente responda, lo que impide el sondeo activo: un censor que se conecta a tu dirección para comprobar si habla Tor no recibe respuesta ni obtiene información.

¿Qué transporte conectable debería ejecutar?

• obfs4 necesita un VPS, dos puertos TCP y ningún nombre de dominio. Es la opción útil más sencilla que puede ejecutar y es el tema de esta guía.
• WebTunnel oculta la conexión dentro del tráfico HTTPS normal dirigido a un sitio web real. Tor Project indica como requisitos una dirección IPv4 estática, un dominio bajo su control, un servidor web operativo como NGINX o Apache, un certificado TLS válido y al menos 1 GB de RAM; recomienda 4 GB. Es adecuado para redes donde el tráfico con aspecto aleatorio resulta sospechoso por sí mismo, porque un país que permite poco más que navegar por la web sigue permitiendo HTTPS.
• Snowflake es una contribución diferente. Los voluntarios ejecutan proxies WebRTC de corta duración, por lo que los puntos de entrada cambian constantemente y no existe una dirección estable que un censor pueda bloquear. No debe operar un bridge para este transporte. Debe ejecutar un proxy, que no necesita una dirección fija.

Empiece con obfs4. Más adelante puede añadir un bridge WebTunnel en una segunda dirección. Ejecutar ambos en una sola IP significa que el bloqueo de una única dirección dejaría fuera de servicio a los dos.

¿Qué coste tiene ejecutar un bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

En agosto de 2026, Tor Project exige que un bridge tenga al menos 1 Mbit/s de ancho de banda de subida y bajada. Para un relay guard o middle se exigen 10 Mbit/s, y se recomiendan 16 Mbit/s. Estos son requisitos publicados, no mediciones. Un bridge nuevo suele mantenerse muy por debajo de su mínimo durante semanas. La misma página de requisitos exige a un relay al menos 100 GByte de tráfico saliente al mes, una cantidad que los planes más pequeños ya cubren. Por eso, consulte cuánto cuesta realmente un VPS pequeño al mes antes de elegir un tamaño mayor.

La superficie de abuso es pequeña, y este es el aspecto que suele entenderse mal. Un bridge es el primer salto. El tráfico que sale de su servidor va a otro relay de Tor, nunca al sitio web que haya elegido un usuario. Su dirección IP nunca aparece en el registro web de un tercero como origen de una petición. Por tanto, los mensajes de abuso que gestionan los operadores de relays de salida no llegan a este servidor. Revise de todos modos la política de uso aceptable de su proveedor, porque algunos hosts tratan cualquier servicio de Tor como un caso especial. Un bridge y un servicio onion son imágenes inversas en este sentido: un bridge sólo es útil porque su dirección es accesible y acaba distribuyéndose, mientras que un servicio onion v3 en el mismo tipo de VPS sólo es útil mientras su IP pública permanezca oculta.

Hay algo que no debe hacer: convertir un relay público existente en un bridge usando la misma dirección. El consejo de Tor Project para ese caso es cambiar la «dirección IP, el nombre y la huella», porque la dirección antigua ya figura en el consenso que descargan los censores. Un bridge que era un relay público la semana pasada es un bridge que ya figura en una lista de bloqueo.

La disponibilidad importa más que la velocidad. Los requisitos para relays indican que «si su relay no funciona durante más de 2 horas al día, su utilidad es limitada». En este aspecto, un bridge está en peor situación que un relay, porque cada cliente tiene una sola dirección y no dispone de una alternativa. Un reinicio desconecta a todos sus usuarios. Configure una comprobación de puerto TCP en Uptime Kuma contra el puerto de obfs4 para saber el día en que deja de responder.

Instalar Tor desde el repositorio del proyecto Tor

Los paquetes de la distribución suelen estar desactualizados, y un bridge es software de seguridad que debe mantenerse actualizado. Añada primero el repositorio propio del proyecto.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Ahora escriba el archivo de origen. La línea Suites: debe contener el nombre en clave de su versión, así que léalo del sistema en lugar de escribirlo de memoria.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Si apt update indica que el repositorio no tiene un archivo Release para su nombre en clave, el proyecto Tor no ofrece esa versión. Elimine /etc/apt/sources.list.d/tor.sources, vuelva a ejecutar sudo apt update e instale el paquete tor que proporciona su distribución. Todo lo que sigue es idéntico.

El paquete obfs4proxy procede directamente de Debian y Ubuntu (versión 0.0.14 en Debian 13, a fecha de agosto de 2026). Confirme dónde se instaló el binario, porque su ruta se incluye en la configuración:

command -v obfs4proxy || command -v lyrebird

El proyecto original cambió su nombre a lyrebird, por lo que un paquete más reciente puede instalar /usr/bin/lyrebird en su lugar. Use la ruta que muestre ese comando.

Configurar el bridge en /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Cada una de esas líneas tiene un fallo asociado, así que revíselas una por una.

BridgeRelay 1 indica a tor que envíe su descriptor a la autoridad de bridges en lugar de al consenso público. Esta única línea hace que el relay no aparezca en las listas públicas.

ORPort es el puerto real de Tor. Debe ser accesible desde Internet, porque tor lo comprueba y se niega a publicar un descriptor hasta que la prueba se complete correctamente.

ServerTransportPlugin proporciona a tor el comando que debe ejecutar. tor inicia obfs4proxy como proceso hijo y se comunica con él mediante una tubería. Por eso obfs4proxy no tiene su propia unidad de servicio y nunca aparece en systemctl status.

ServerTransportListenAddr fija el puerto en el que escucha obfs4proxy. Si omite esta línea, obfs4proxy selecciona un puerto libre al iniciar y normalmente elige otro después de cada reinicio. Por tanto, cada línea de bridge que ya haya distribuido apunta a un puerto en el que no escucha ningún proceso. Esos clientes reciben una conexión rechazada y dejan de intentarlo.

ExtORPort auto abre el ORPort extendido, un canal de loopback que obfs4proxy usa para devolver a tor las conexiones establecidas junto con la dirección del cliente. La guía de configuración de Tor Project lo incluye en todos los bridges, porque sin él el transporte no puede informar de esa dirección a tor.

ContactInfo y Nickname son públicos. Use una dirección que vaya a leer, porque Tor Project la utiliza para ponerse en contacto con usted si un bridge deja de funcionar. Elija un apodo que no permita identificarle si prefiere mantener un perfil discreto.

BridgeDistribution selecciona el distribuidor que entrega su dirección a los usuarios. Los valores aceptados son https, email, telegram, settings, none y any. Use any para un primer bridge y deje que el sistema decida. Use none para un bridge privado que distribuya usted mismo. Así, la dirección queda completamente fuera de la distribución pública.

Por qué importa elegir bien los puertos

Evite usar 9001 para ambos puertos. Tor Project lo indica expresamente porque 9001 es el ORPort tradicional y los censores escanean Internet en busca de ese puerto. Los dos puertos también deben ser diferentes, ya que tor y obfs4proxy abren cada uno su propio listener.

El puerto obfs4 más eficaz es 443. El tráfico saliente hacia 443 está permitido en casi todas las redes restringidas, y una conexión persistente con ese puerto parece una sesión web normal. Asociar un servicio a un puerto inferior a 1024 requiere un paso adicional porque obfs4proxy no se ejecuta como root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Añada estas dos líneas en cada editor que se abra:

[Service]
NoNewPrivileges=no

La capacidad por sí sola no es suficiente. El NoNewPrivileges de systemd impide que un proceso obtenga privilegios que su proceso padre no tenía, y una capacidad de archivo es precisamente eso. Por tanto, obfs4proxy no puede asociarse al puerto 443 mientras esta configuración siga activa.

Si prefiere omitir ese paso, elija un puerto alto poco llamativo y anótelo. Sea cual sea su elección, no cambie después el puerto de obfs4. Una línea de puente vincula la dirección, el puerto, la huella digital y el certificado. Por eso, todas las copias que ya estén guardadas en el navegador de un usuario dejan de funcionar en cuanto cambia el puerto.

Abre los puertos en ambos firewalls

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Ambos puertos deben estar abiertos. La mayoría de los proveedores ejecuta un segundo firewall en su panel de control que ufw no puede consultar. Una regla que existe en el servidor, pero no en el panel, crea un bridge que nunca es accesible y nunca publica un descriptor. Si alguna de las dos partes es nueva para usted, las reglas de ufw que necesita un VPS recién instalado y qué es realmente un puerto en escucha en Linux explican los conceptos básicos. Aproveche también para proteger SSH con claves y una configuración reforzada de sshd. Un bridge no listado en un servidor con SSH mediante contraseña sigue siendo un servidor con SSH mediante contraseña.

Inícielo y lea el registro

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian y Ubuntu incluyen dos unidades. tor.service es un contenedor pequeño y tor@default.service es el proceso que realiza el trabajo. Por eso journalctl -u tor parece casi vacío, mientras que el registro que necesita está en tor@default.

Dos líneas indican que funcionó:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

La primera indica que la prueba de accesibilidad se completó correctamente y que el descriptor se envió a la autoridad de bridges. Si nunca aparece, algún elemento entre Internet y el servidor está descartando el tráfico hacia el ORPort. La segunda línea debe mostrar el puerto que configuró. Si muestra otro puerto, tor nunca aplicó ServerTransportListenAddr. La causa habitual es que el nombre del transporte no coincida: debe aparecer como obfs4 en ambas directivas.

Confirme que existen los dos procesos a la escucha:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

¿Dónde está mi línea de bridge?

obfs4proxy escribe una plantilla en el directorio de datos de tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Ese directorio pertenece al usuario tor y tiene el modo 700, por lo que sin sudo obtendrá Permission denied. El archivo contiene una línea con este formato:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Sustituya <IP ADDRESS> por la dirección pública de su servidor, <PORT> por el puerto de obfs4, no por el ORPort, y <FINGERPRINT> por la huella de identidad que tor escribió en su directorio de datos:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

El primer archivo contiene el apodo y la huella de identidad que deben aparecer en una línea de bridge. El segundo contiene la huella calculada, que debe pegar en Relay Search para comprobar si su bridge está activo y obtener una estimación de cuántos clientes acceden a él. No son intercambiables. Una línea de bridge que contiene el valor calculado no coincide con la clave de identidad que presenta su bridge, por lo que el cliente rechaza la conexión que acaba de abrir.

¿Cómo llega realmente un bridge a los usuarios?

No debe entregar la línea de su bridge a cualquier persona. Cuando el descriptor llega a la autoridad de bridges, el sistema de distribución (rdsys, el sucesor de BridgeDB) asigna su bridge a un distribuidor, y los usuarios solicitan bridges a ese distribuidor. En agosto de 2026, las vías son estas:

• El formulario web de bridges.torproject.org/options, que muestra líneas de bridges después de resolver un captcha.
• Un correo a bridges@torproject.org desde una dirección de Gmail o Riseup, que responde con líneas de bridges. La restricción del proveedor existe porque las cuentas gratuitas ilimitadas permitirían que un censor enumerara todos los bridges.
• El bot de Telegram @GetBridgesBot. Envíe /start y, después, /obfs4 o /webtunnel.
• El propio Tor Browser, en Settings y después Connection, donde "Request bridges" los obtiene a través del canal moat.

Un bridge nuevo aparece en Relay Search aproximadamente tres horas después de configurarlo. Los usuarios tardan mucho más: la formulación del propio Tor Project es que "Pueden pasar varios días o semanas hasta que vea un conjunto constante de usuarios". Es normal que haya poca actividad durante las dos primeras semanas. No indica un fallo.

Configurar BridgeDistribution none excluye el bridge de todo esto. La línea del bridge queda a su disposición para enviarla a las personas que la necesiten, mediante un canal que el censor no esté supervisando.

Cuando algo no funciona

No aparece la línea de autocomprobación en el registro. ORPort no es accesible. Pruébelo desde otra máquina con nc -vz your.ip 8443. Si la conexión queda bloqueada, los paquetes se están descartando; compruebe ufw y el panel del proveedor. Si la conexión se rechaza, tor no está escuchando; compruebe ss -lntp y revise el registro en busca de un error de configuración.

El transporte registrado muestra un puerto que no seleccionó. tor ignoró ServerTransportListenAddr. El nombre del transporte debe coincidir exactamente con el de ServerTransportPlugin, y ambos deben estar en obfs4.

obfs4proxy no puede asociarse al puerto 443. Confirme la capacidad con getcap /usr/bin/obfs4proxy y compruebe que la sobreescritura haya llegado a la unidad con systemctl show tor@default -p NoNewPrivileges. Si muestra NoNewPrivileges=yes, el drop-in se aplicó a una unidad que no está en ejecución.

No hay nada dentro de /var/lib/tor/pt_state/. tor nunca inició el transporte, lo que significa que la ruta de ServerTransportPlugin es incorrecta. Compárela con la salida de command -v obfs4proxy.

Los clientes dejaron de conectarse después de un cambio. Cualquier cambio en la dirección o en el puerto de obfs4 invalida todas las líneas de bridge distribuidas anteriormente. Compruebe también si cambió la IP pública del servidor. Esto puede ocurrir al reconstruir el servidor con algunos proveedores.

tor no inicia en absoluto. Ejecute sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Analiza el archivo, muestra la línea problemática y deja intacto el servicio en ejecución.

FAQ

¿Mi proveedor de VPS se quejará de un bridge de Tor?

Un bridge es un punto de entrada, por lo que el tráfico que sale de su servidor se dirige a otros relays de Tor y nunca a un sitio elegido por un usuario. Su dirección IP no aparece en los registros web de nadie como origen de una solicitud. Eso es lo que genera las quejas que reciben los operadores de relays de salida. Las reglas de alojamiento varían, y algunos proveedores tratan cualquier servicio de Tor como un caso especial. Lea la política de uso aceptable antes de empezar y coloque una dirección que haya leído en ContactInfo.

¿Cuánto ancho de banda utiliza un bridge de Tor?

El mínimo publicado es de 1 Mbit/s de subida y bajada, frente a 10 Mbit/s para un relay guard o middle. El uso real comienza cerca de cero, porque su bridge sólo transporta tráfico de los usuarios que un distribuidor le envía. Si necesita un límite máximo fijo, configure RelayBandwidthRate y RelayBandwidthBurst en torrc.

¿Por qué nadie se ha conectado a mi bridge nuevo?

Un bridge tarda unas tres horas en aparecer en Relay Search. Las indicaciones de Tor Project señalan que se necesita un conjunto constante de usuarios durante varios días o semanas. Compruebe que se haya publicado el descriptor, que es la línea de autocomprobación de journalctl -u tor@default. Busque su fingerprint con hash en Relay Search y confirme que BridgeDistribution no esté configurado como none.

¿Debo ejecutar obfs4 o WebTunnel?

Ejecute obfs4 si este es su primer bridge: un VPS, dos puertos, ningún dominio y ningún certificado. Ejecute WebTunnel cuando también se bloquee el tráfico que parece aleatorio, ya que necesita un dominio bajo su control, un servidor web real, un certificado TLS válido y al menos 1 GB de RAM. Use direcciones separadas si ejecuta ambos, porque una IP bloqueada eliminaría dos bridges a la vez.

¿Qué ocurre si cambio después el puerto de obfs4?

Todas las líneas de bridge ya distribuidas dejan de funcionar. Una línea de bridge vincula la dirección, el puerto, el fingerprint y el certificado. Por tanto, un cliente que conserve la línea antigua abre una conexión a un puerto donde no escucha ningún servicio y abandona. Lo mismo ocurre cuando cambia la IP pública del servidor. Elija el puerto durante la configuración y no lo cambie.