SSD Nodes Learn Hosting plans →
Guías Matt ConnorPor Matt Connor · Actualizado 2026-08-24

Cómo ejecutar un relay de Tor en un VPS

Configura un relay guard o middle de Tor en un VPS Linux con torrc, límites para planes medidos, nyx y una incorporación gradual al consenso.

Qué hace un relay de Tor en un VPS

Un relay de Tor es un daemon de Tor en una máquina con una dirección IP pública que reenvía tráfico cifrado para otras personas. Las autoridades de directorio lo publican y los clientes de Tor construyen circuitos a través de él. Un relay guard o middle sólo entrega el tráfico a otro relay, por lo que nunca abre una conexión con un sitio web en nombre de un desconocido. Ese hecho explica por qué no recibe mensajes de abuso y por qué es la contribución adecuada para un VPS común. Un relay transporta el tráfico de otras personas y no publica nada propio. Por tanto, si lo que quiere es poner su propio sitio en la red en lugar de transportar paquetes para él, ejecutar un servicio onion v3 detrás de nginx es una tarea diferente para el mismo daemon de tor. Ejecutar un relay tampoco mejora la privacidad de su propia navegación. Ese es un problema independiente y ofrece menos privacidad de la que la mayoría espera: qué oculta realmente alojar SearXNG permite medir hasta dónde llega trasladar un servicio a su propio VPS.

El trabajo es sencillo: un paquete, quince líneas de configuración, una regla del firewall y un reinicio. El resto de esta guía trata los problemas habituales. Incluye el cálculo del ancho de banda en un plan medido y la razón por la que un relay nuevo y perfectamente operativo parece estar inactivo durante una semana.

Guard, middle, bridge o exit: elige antes de instalar

Un daemon ejecuta los cuatro roles. Tu configuración y las autoridades del directorio determinan cuál eres.

  • Relay middle. Recibe tráfico de un guard y lo pasa a otro relay. Nunca se conecta a un sitio de destino. Todo relay nuevo empieza aquí.
  • Relay guard. Usa la misma configuración, con un flag adicional. Las autoridades del directorio asignan el flag Guard a los relays que han sido rápidos y estables durante el tiempo suficiente. No puedes elegirlo. Debes conseguirlo, y la configuración siguiente es la que permite conseguirlo.
  • Bridge. Es un relay que se mantiene deliberadamente fuera del directorio público y se entrega de forma privada a usuarios en lugares donde Tor está bloqueado. Es el compromiso más pequeño de los cuatro: poco ancho de banda, sin publicación pública y un primer paso adecuado si tu plan es pequeño. También necesita un proxy obfs4 ejecutándose junto al daemon y un conjunto diferente de líneas de torrc. La configuración de un bridge obfs4 en un VPS económico explica el proceso, incluido cómo se entrega al final la línea del bridge a los usuarios.
  • Relay exit. Es el último salto y abre la conexión con el sitio de destino. Cada solicitud de un usuario sale desde tu dirección IP, por lo que los informes de abuso y las consultas policiales llegan al titular de esa dirección.

El exit es el único rol que no debe ejecutarse en un VPS de propósito general. Ejecuta un exit sólo con un proveedor que haya aceptado previamente recibir esos mensajes, que proporcione una dirección IP propia y que publique un contacto de abuso. La mayoría de las condiciones de los servicios de hosting lo prohíben. El resultado habitual de ignorarlo es la suspensión del servidor y la pérdida de la dirección IP. Si ese es el trabajo que quieres realizar, Qué implica realmente ejecutar un relay exit explica cómo encontrar un host compatible con exits, definir la política del exit y el reverse DNS, y responder a los mensajes cuando lleguen. Un relay guard o middle transporta el mismo tráfico de usuarios sin ninguna de esas exposiciones.

Todo lo siguiente configura un relay guard/middle. ExitRelay 0 es la línea que lo mantiene como uno de esos dos roles.

Lo que necesita el VPS antes de empezar

The Tor Project publica requisitos estrictos para los relays. En agosto de 2026 son los siguientes: una dirección IPv4 pública para el relay, al menos 10 Mbit/s de ancho de banda en cada dirección, con 16 Mbit/s como valor recomendado, al menos 100 GB de tráfico saliente al mes y 512 MB de RAM por debajo de 40 Mbit/s, o 1 GB por encima de esa velocidad. No existe una regla fija de disponibilidad, pero un relay que funciona menos de dos horas al día aporta poca utilidad a la red.

La cifra de 10 Mbit/s describe la línea, no la configuración. Necesita un puerto que pueda alcanzar esa velocidad. La cantidad de esa línea que permite usar al relay es una decisión independiente, que debe tomar teniendo en cuenta el límite mensual de transferencia. Revise su plan antes de modificar la configuración. Si todavía está eligiendo un servidor, cuánto cuesta realmente un VPS al mes explica cómo se comercializan los límites de transferencia, y cómo medir el rendimiento de red real de un VPS muestra cómo comprobar qué rendimiento ofrece la línea con iperf3 en lugar de confiar en la página comercial.

Endurezca la máquina primero. Un relay es un servicio público en una dirección pública, y esa dirección recibe escaneos pocos minutos después de publicarse. Restringir SSH a claves y aplicar una configuración de sshd reforzada lleva diez minutos y debe hacerse antes de poner el relay en producción, no después.

Instalar Tor desde el repositorio de Tor Project

Use el repositorio apt propio de Tor Project en lugar del paquete de la distribución. El código del relay avanza más rápido que una versión estable, por lo que las correcciones llegan primero a este repositorio y el paquete de la distribución queda desactualizado entre versiones.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Añada la clave de firma y, después, el repositorio. El nombre en clave se obtiene de la máquina, por lo que el mismo bloque funciona en Ubuntu 24.04 (noble) y Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
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
tor --version

tor --version muestra la versión que acaba de instalar. Si apt update muestra un error NO_PUBKEY, la clave desarmada no está en la ruta indicada en la línea Signed-By:, por lo que apt no tiene ninguna clave con la que verificar el archivo de versión. El paquete deb.torproject.org-keyring será necesario más adelante: proporciona la clave de firma como un paquete normal, de modo que apt sigue funcionando cuando se sustituye esa clave.

Active las actualizaciones automáticas y, después, indíqueles el nuevo origen.

sudo apt install -y unattended-upgrades apt-listchanges

En Ubuntu, añada el origen de Tor al bloque Allowed-Origins en /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

En Debian, el mismo archivo usa Origins-Pattern. La línea que debe añadir es "origin=TorProject";. Compruebe el resultado con sudo unattended-upgrade --debug --dry-run, que muestra los orígenes sobre los que actuará y no escribe nada.

El torrc que importa

El paquete instala un archivo /etc/tor/torrc extenso y con muchos comentarios. Para un relay sólo importan unas pocas líneas. Añádalas al final del archivo.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname tiene entre 1 y 19 caracteres y sólo puede contener letras y dígitos. No es único en la red; la identidad del relay es la huella digital. Este nombre permite localizar el relay en un cuadro de búsqueda, así que elija uno que pueda deletrear por teléfono.

ContactInfo se publica dentro del descriptor del relay. Este descriptor es un documento público que cualquiera puede descargar, por lo que la dirección se recopilará. Use una dirección que todavía vaya a leer dentro de dos años y ofúsquela si lo desea. Este es el único canal que tiene el Tor Project para avisarle de un problema con el relay.

ORPort 9001 es el puerto al que se conectan otros relays y clientes. 9001 es el valor habitual. El puerto 443 es la otra opción común, porque algunas redes restrictivas sólo permiten conexiones salientes al puerto 443. Por tanto, un relay que escuche en ese puerto será accesible para más clientes. Elija 443 sólo si ningún otro servicio del equipo lo necesita.

SocksPort 0 desactiva el proxy SOCKS local, que un relay no utiliza, y elimina un socket de escucha del equipo. ExitRelay 0 deja constancia de esta intención en el archivo: este relay nunca se conectará a un destino en nombre de un usuario, y quien revise la configuración más adelante no tendrá que deducirlo a partir del valor predeterminado.

Si el VPS tiene una dirección IPv6, añada una segunda línea ORPort. Tor no puede enlazarse a cualquier dirección IPv6 de la misma forma que lo hace con IPv4, así que escriba la dirección entre corchetes.

ORPort 9001
ORPort [2001:db8::1]:9001

En un VPS de 1 GB, añada MaxMemInQueues 512 MB. Tor calcula el límite de su cola a partir de la memoria que detecta en el equipo. En un equipo compartido pequeño, ese límite puede ser superior al que conviene utilizar. Si establece el límite manualmente, tor descartará las celdas en cola cuando haya presión de memoria. El relay seguirá funcionando en lugar de aumentar el consumo hasta que el kernel termine el proceso.

Abrir el ORPort en el firewall

En sentido entrante, el ORPort debe ser accesible desde cualquier lugar de Internet. En sentido saliente, deje el relay sin restricciones: abre conexiones con miles de otros relays en muchos puertos distintos, y una lista de permitidos para el tráfico saliente lo dejará prácticamente inutilizado sin mostrar un error claro.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

Después, compruebe el firewall de red del proveedor. Muchos paneles de control ejecutan un filtro de paquetes delante de la máquina virtual. Por eso, una regla que añada con ufw no tiene efecto allí: el puerto aparece abierto en el servidor, pero cerrado desde el exterior. Si no conoce ufw, las reglas de ufw que deben estar en todos los VPS explica la política predeterminada y el orden en que se aplican las reglas.

Ajuste el ancho de banda a su plan

El manual describe RelayBandwidthRate como un depósito de tokens independiente que limita «el uso medio del ancho de banda entrante para el tráfico retransmitido en este nodo al número de bytes por segundo especificado, y el uso medio del ancho de banda saliente al mismo valor». Léalo dos veces. El límite se aplica por separado a cada dirección. Un relay configurado a 1 Mbit/s puede transferir 1 Mbit/s de entrada y 1 Mbit/s de salida al mismo tiempo, y un proveedor que contabiliza ambas direcciones factura la suma.

ChartMonthly traffic at a sustained relay rate, both directions, 30 days
The data behind this chart
[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Esas 5 filas son cálculos aritméticos, no mediciones: muestran cuánto cuesta una tasa si el relay la mantiene durante 30 días completos en ambas direcciones. Un relay permanece por debajo de su límite buena parte del tiempo, especialmente durante las primeras semanas. Use la tabla para descartar configuraciones que no puede asumir, no para predecir una factura al gigabyte.

A 1 Mbit/s en cada dirección, un relay transfiere aproximadamente 21.6 GB al día, por lo que un mes de 30 días consume aproximadamente 648 GB de tráfico contabilizado. Esto cabe dentro de una asignación de 1 TB y deja margen para actualizaciones y copias de seguridad. Si sube a 2 Mbit/s, el mes consume 1,296 GB, una cantidad que ya supera un plan de 1 TB. La última fila, 20 Mbit/s, necesita 12,960 GB al mes y debe usar un puerto sin límite de tráfico. Si su proveedor factura sólo el tráfico saliente, divida todas las cifras por dos. Averigüe cuál de los dos casos se aplica antes de configurar la tasa, porque las respuestas difieren por un factor de dos.

Ahora, la configuración. Primero limite la tasa y después establezca la cuota.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst es el tamaño del depósito de tokens, por lo que permite picos breves por encima de la tasa mientras se mantiene la media. Un valor aproximadamente igual al doble de la tasa es adecuado.

AccountingRule es la línea que más operadores pasan por alto. El valor predeterminado es max, que compara con la cuota la mayor de las dos direcciones. Con el valor predeterminado, AccountingMax 400 GBytes permite 400 GB de entrada y 400 GB de salida, es decir, 800 GB en un medidor que contabiliza ambas direcciones. AccountingRule sum suma las lecturas y las escrituras contra una única cuota, que es lo que mide realmente una asignación de transferencia.

Escriba también AccountingStart; nunca use AccountingMax de forma independiente. La cuota es el número, y la línea de inicio indica el periodo en el que se restablece. Una cuota sin periodo deja al relay en hibernación sin nada que lo reactive.

La hibernación es un mecanismo brusco. Cuando se agota la cuota, tor lo registra y deja de aceptar trabajo:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

El relay tampoco se reactiva exactamente al inicio del periodo siguiente. Tor registra la velocidad a la que consumió la cuota anterior y elige un momento aleatorio dentro del nuevo intervalo, para evitar que miles de relays regresen a la red en el mismo segundo. Un relay que desaparece durante la última semana de cada mes pierde continuamente la estabilidad que miden las autoridades del directorio. Ajuste RelayBandwidthRate para que nunca se alcance el límite y mantenga AccountingMax como protección final de la factura.

Inicie el relay y confirme que es accesible

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

En unos minutos, el registro debería contener esta línea:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Esto significa que otros relays se conectaron a su ORPort y construyeron un circuito a través de él. Hasta que aparezca, su relay no figura en el directorio y no transporta tráfico. El error tiene este aspecto:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Revíselo en este orden. Compruebe si el ORPort está abierto en ufw. Compruebe también si está abierto en el firewall de red independiente del proveedor. Verifique que la dirección de ese mensaje sea la dirección a la que Internet realmente enruta las conexiones, y no una dirección privada de una configuración NAT. Pruebe el puerto desde otra máquina con nc -vz 203.0.113.10 9001. Tor repite automáticamente la prueba de accesibilidad, por lo que detecta un firewall corregido sin intervención adicional. Un reinicio hace que la comprobación sea inmediata.

La identidad permanente de su relay es su fingerprint:

sudo cat /var/lib/tor/fingerprint

Unas tres horas después de publicar el descriptor, el relay aparece en Relay Search. Busque el nickname o pegue el fingerprint. Esa página muestra cómo ve la red su relay: qué flags tiene, qué weight le asignan las autoridades y qué versión publica.

¿Por qué un nuevo relay de Tor casi no recibe tráfico?

Porque la red todavía no lo ha medido, y la medición tarda semanas. El Tor Project describe este proceso en cuatro fases. Un operador que no lo ha leído concluye que el relay está averiado y empieza a cambiar cosas.

Durante los primeros tres días, el relay no tiene mediciones. Informa del resultado de su propia prueba, pero las autoridades de directorio limitan de todos modos el peso publicado a 20 KB. Por eso, los clientes casi nunca lo seleccionan. Desde aproximadamente el tercer día hasta el octavo, las autoridades de ancho de banda lo miden de forma real y el peso aumenta. Sin embargo, sólo se usa como salto intermedio, porque ningún cliente está dispuesto a convertir un relay completamente nuevo en su primer salto.

Alrededor del octavo día, el relay puede obtener la marca Guard. Obtener esta marca hace que el tráfico disminuya, lo que sorprende a muchos operadores. Al elegir saltos intermedios, los clientes omiten los guards porque asumen que un guard ya está ocupado. Por tanto, el relay pierde tráfico intermedio antes de ganar tráfico como guard. Sólo recupera tráfico a medida que los clientes rotan sus conjuntos de guards, un proceso que tarda semanas. Aproximadamente en el día 68 alcanza un estado estable, en el que los clientes que dejan de usarlo compensan a los clientes que empiezan a usarlo.

Por tanto, la expectativa realista es no recibir nada durante tres días, recibir algo después de una semana y obtener una carga significativa después de dos meses. Cambie una sola configuración y espere una semana para comprobar sus efectos. Una página de estado de Uptime Kuma autohospedada con una comprobación TCP contra el puerto 9001 es una mejor forma de aprovechar la preocupación: responde a la pregunta que realmente puede controlar, que es si el puerto sigue respondiendo.

Supervise el relay con nyx

nyx es el monitor de terminal de un relay en ejecución. Se comunica con el puerto de control de tor, por lo que debe habilitarlo primero en torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort sólo escucha en 127.0.0.1, y la autenticación mediante cookie obliga a los programas a leer un archivo secreto antes de poder emitir comandos. Tor escribe esa cookie en /run/tor/control.authcookie como el usuario debian-tor, con el modo 600, para que ningún otro usuario pueda leerla. CookieAuthFileGroupReadable 1 da acceso al grupo, lo que permite que su propia cuenta ejecute nyx sin sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Cierre la sesión y vuelva a iniciarla. Después, ejecute nyx. El nuevo grupo debe incorporarse al iniciar sesión. Por eso, si ejecuta nyx en la misma sesión de shell, aparecerá un error de permisos en el archivo de cookie aunque la configuración sea correcta. nyx muestra el ancho de banda en tiempo real, el tiempo de actividad, el flujo de registros y la lista de conexiones. Durante las primeras semanas, debe vigilar que el gráfico de ancho de banda se mantenga por debajo de RelayBandwidthRate.

Ejecutar más de un relay: MyFamily y claves de familia

Con un solo relay, omita esta sección. Dos o más relays administrados por el mismo operador deben declararse entre sí. Así, los clientes nunca construirán un circuito que entre y salga por sus máquinas, lo que permitiría a un operador ver ambos extremos.

El método tradicional consiste en usar MyFamily en el torrc de cada relay y especificar las huellas digitales de todos los demás:

MyFamily AAAAAAAAAA,BBBBBBBB

Cada relay especifica todos los demás. Por tanto, añadir un cuarto relay implica editar cuatro archivos. Tor 0.4.9 sustituyó este método por una clave de familia. Genere una clave y compártala:

tor --keygen-family myfamily

Este comando escribe myfamily.secret_family_key e imprime una línea FamilyId. Copie el archivo de clave a cada relay, en el subdirectorio keys de DataDirectory (/var/lib/tor/keys en Debian y Ubuntu), y conserve el sufijo .secret_family_key. Añada la línea FamilyId impresa al torrc de cada relay y recargue con sudo systemctl reload tor@default. Mantenga también la lista MyFamily por ahora. Los clientes que todavía no entienden los certificados de familia siguen leyendo la lista heredada. El Tor Project anunciará cuándo se podrá eliminar.

Qué falla después de que está en ejecución

La versión queda obsoleta. Las actualizaciones desatendidas reemplazan el paquete, pero el proceso en ejecución sigue usando el binario con el que se inició hasta que algo lo reinicia. Compare tor --version en el equipo con la versión que aparece en la página Relay Search del relay. Si son distintas, la red sigue viendo la versión antigua, por lo que debe reiniciar el servicio.

El reloj se desajusta. Los documentos de consenso y los certificados están sujetos a intervalos de validez, por lo que una máquina cuyo reloj está muy adelantado o atrasado rechaza el consenso y deja de publicar. timedatectl debe indicar que el reloj del sistema está sincronizado. Si no lo está, habilite systemd-timesyncd o instale chrony.

La dirección IP cambia. El descriptor contiene la dirección, y los clientes no pueden acceder a una dirección que ha cambiado. Después de cualquier migración de proveedor o cambio de dirección, reinicie tor y vuelva a supervisar la línea de prueba automática.

El relay es más lento de lo que permite el plan. La criptografía de relay de Tor es eficiente en los procesadores modernos, y Tor Project estima que una CPU compatible con AES-NI alcanza aproximadamente entre 400 y 450 Mbit/s en cada dirección. Mucho antes de llegar a ese límite, estará limitado por la velocidad del puerto y la cuota de transferencia. Por eso, la sección de contabilidad anterior es más importante que el hardware.

FAQ

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

Utiliza tanto como permita, y nada más. RelayBandwidthRate limita el tráfico retransmitido por separado en cada dirección, por lo que un relay configurado a 1 Mbit/s puede transportar 1 Mbit/s de entrada y 1 Mbit/s de salida al mismo tiempo. Esto equivale aproximadamente a 21.6 GB al día, o 648 GB durante un mes de 30 días, contando ambas direcciones. Añada AccountingMax con AccountingRule sum como cuota mensual máxima por debajo de esa tasa.

¿Ejecutar un relay de Tor hará que reciba quejas por abuso?

Un relay guard o middle sólo pasa tráfico a otros relays de Tor y nunca se conecta a un sitio web en nombre de un usuario. Por tanto, las quejas sobre lo que alguien hizo a través de Tor llegan al operador del relay exit, no a usted. Puede recibir escaneos y alguna inclusión ocasional en listas de reputación de IP, porque la dirección aparece publicada como relay. Los relays exit son los que reciben mensajes de abuso y notificaciones legales, y necesitan un proveedor que haya aceptado gestionarlos de antemano. Lea las condiciones de su proveedor antes de iniciar cualquiera de los dos tipos.

¿Por qué mi nuevo relay de Tor no recibe tráfico?

Porque los relays nuevos tienen un límite de tráfico por diseño hasta que se miden. Durante los primeros tres días, las autoridades de directorio limitan el peso publicado a 20 KB, por lo que los clientes casi nunca eligen el relay. Las autoridades de ancho de banda lo miden a partir de aproximadamente el tercer día. El relay puede obtener el indicador Guard alrededor del octavo día, y el tráfico vuelve a disminuir en ese momento porque los clientes evitan los guards al elegir saltos middle. La carga completa llega alrededor del día 68. Confirme que el registro muestra "Self-testing indicates your ORPort is reachable from the outside" y, después, no intervenga.

¿Puedo ejecutar un relay de Tor en un VPS con una cuota de transferencia de 1 TB?

Sí, a aproximadamente 1 Mbit/s en cada dirección, lo que equivale a RelayBandwidthRate 125 KBytes. Esto supone aproximadamente 648 GB al mes si su proveedor contabiliza ambas direcciones, y deja margen para actualizaciones y copias de seguridad. Añada AccountingMax 400 GBytes con AccountingRule sum y AccountingStart month 1 00:00 para que el relay entre en hibernación en lugar de superar la cuota contratada. Si el proveedor factura sólo la salida, puede duplicar la tasa.

¿Tengo que configurar MyFamily si ejecuto un solo relay?

No. Las declaraciones de familia existen para que los clientes eviten crear un circuito a través de dos relays propiedad del mismo operador, algo que no tiene sentido con un solo relay. Configúrela en cuanto añada un segundo relay: indique la huella digital de cada relay en la línea MyFamily de todos los relays, o utilice la clave de familia que introdujo Tor 0.4.9, que distribuye un único FamilyId en lugar de una lista cada vez más larga.