Setup of dual tor relays seems to be ignored

Support Relay Operator
1

System info
OS: (headless) Debian 13
Tor version 0.4.9.9.Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.5.6, Zlib 1.3.1, Liblzma 5.8.1, Libzstd 1.5.7 and Glibc 2.41 as libc. Tor compiled with GCC version 14.2.0

relay1 specific torrc settings
fingerprint1: C1001E311B15BCAEF21AFEDE50C78A8502032C4F
Nickname TrixieRelay1
ORPort 443

relay2 specific torrc settings
fingerprint2: 64C412BAB711834AA21CE430F64A0377869E0605
Nickname TrixieRelay2
ORPort 9001

common torrc settings
IPv4Only
MyFamily 64C412BAB711834AA21CE430F64A0377869E0605,C1001E311B15BCAEF21AFEDE50C78A8502032C4F
NumCPUs 2
AssumeReachable 1 #since router/firewall doesn’t support hairpin NAT
CookieAuthentication 1
ExitRelay 0
ExitPolicy reject :SocksPort 0
RelayBandwidthRate 2500 KBytes
RelayBandwidthBurst 4 MBytesAccountingMax 2 TBytes

confirmed so far with nc:
nc -zv 180.20.55.204 443
[180.20.55.204] 443 (https) open

nc -zv 180.20.55.204 9001
[180.20.55.204] 9001 (?) open

confirmed so far with curl:
curl -s “``http://131.188.40.189:80/tor/server/fp/C1001E311B15BCAEF21AFEDE50C78A8502032C4F”`` | head -3
router TrixieRelay1 180.20.55.204 443 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----

curl -s “``http://171.25.193.9:443/tor/server/fp/C1001E311B15BCAEF21AFEDE50C78A8502032C4F”`` | head -3
router TrixieRelay1 180.20.55.204 443 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----

curl -s “``http://131.188.40.189:80/tor/server/fp/64C412BAB711834AA21CE430F64A0377869E0605”`` | head -3
router TrixieRelay2 180.20.55.204 9001 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----

curl -s “``http://171.25.193.9:443/tor/server/fp/64C412BAB711834AA21CE430F64A0377869E0605”`` | head -3
router TrixieRelay2 180.20.55.204 9001 0 0
identity-ed25519
-----BEGIN ED25519 CERT-----

curl -s “``http://128.31.0.39:9131/tor/status-vote/current/authority”`` | grep -i “C1001E311B15BCAE|64C412BAB711834A”
returns nothing

curl -s “``http://128.31.0.39:9131/tor/status-vote/current/consensus”`` | grep -i “TrixieRelay”
returns nothing

online port check
Open Port Check Tool - Test Port Forwarding on Your Router and others show that Port 443 and Port 9001 are open on 180.20.55.204

nyx shows
The directory authorities CAN reach the relays (moria1 (128.31.0.39) and maatuska (171.25.193.9) are actively making inbound connections). The reachability test is therefore happening, i.e. the TCP/TLS layer succeeds.
Yet neither votes the nodes as running. Is there some problem with the handshake or validation that is not satisfying the criteria?

Any suggestions welcome to find out what prevents these nodes from getting up and running as part of the network.

2

Follow up (29 June 2026)
Four directory authorities (dizum, moria1, maatuska, gabelmoo) simultaneously making inbound connections to both relays, all showing UNKNOWN status, yet neither relay appears in the consensus. Still not in consensus after 7+ days total, with current instance running since June 22 17:59 JST (~6.5 days stable uptime.
The observed bandwidth in the descriptor shows only 13312 bytes/s (~13 KB/s), despite the connection being capable of at least 70 Mbps sustained (confirmed via file transfer speedtest over VPN through the same firewall/connection). Bandwidth descriptor shows observed value of only 13312 bytes/s despite advertised 10 MB/s — therefore now increased RelayBandwidthRate from 2500 to 10000 KBytes to give bwauths more room to measure. Why is the observed bandwidth so low, and could this be blocking consensus inclusion? Is there a minimum observed bandwidth threshold required for the Running flag?

Screenshot 1 (TrixieRelay1):
moria1 (128.31.0.39, US) connecting inbound ✓
maatuska (171.25.193.9, SE) connecting inbound ✓
dizum (45.66.35.11, NL) also connecting inbound — that’s a third directory authority!
All show UNKNOWN status despite successful connections
Tor 0.4.9.11 running as recommended (updated automatically to 0.4.9.11 today (June 29)) ✓

Screenshot_20260629_113236
Screenshot_20260629_1132361960×1076 169 KB

  1. Is AssumeReachable 1 known to have any side effects beyond skipping the local self-test in recent Tor versions?
  2. Why would directory authorities connect to the ORPort successfully yet not vote Running?
  3. Is the low observed bandwidth (13312 bytes/s) a hard blocker for consensus inclusion?
  4. Are there known issues with relay inclusion from Japanese IP space?
3

Screenshot 2 (TrixieRelay2):
gabelmoo (131.188.40.189, DE) connecting inbound ✓
Two US IPs also connecting inbound
Again all UNKNOWN

Screenshot_20260629_113031
Screenshot_20260629_1130311920×1036 128 KB

4

Consensus Health shows both relays (C1001E31 TrixieRelay1 & 64C412BA TrixieRelay2) as valid. So the question becomes what prevents all 9 authorities from assigning the “running” flag despite the validation.

  • Is it TLS 1.3 with X25519MLKEM768 post-quantum key exchange (confirmed with tshark) in combination with the traditional MyFamily setting?
  • Is it any other incompatible or insufficient setting?
  • Is it related to some network regulation/control (Japan, NTT) which leads to observed bandwidth only 13312 bytes/s despite 100+ Mbps connection
  • Notable also that according to below attached tshark analysis, dannenberg with its location in Berlin has such a low throughput, despite NTT having at least 3 datacenters just around the corner in Berlin, which all have a direct connection to the network in the company’s homeland in East Asia where this tor relay is set up.
  • 171.25.193.9:60262 ↔ 192.168.13.4:443 14 frames, 15KB, 22.7s (maatuska)
    128.31.0.39:55984 ↔ 192.168.13.4:443 3 frames, 3KB, 0.4s (moria1)
    131.188.40.189:59548 ↔ 192.168.13.4:9001 3 frames, 3KB, 1.1s (gabelmoo)
    193.23.244.244:40331 ↔ 192.168.13.4:443 3 frames, 228B, 16.2s (dannenberg)
5

Hi, can you restart your tor relay daemon and share your tor logs?