[Help] Relays finally start but show 0 bytes of traffic - I’m out of ideas

Support Relay Operator
1

Hi everyone,

I could use a sanity check. All my relays suddenly went offline. I’ve managed to get them to start again, but they now sit there with 0 B traffic (data from metrics). I’m not sure what I’m still missing.

What happened

  • Relays were fine, then from one day to the next they went offline.

  • Nyx kept warning:

    Your server has not managed to confirm reachability for its ORPort(s) at <IP_ADDRESS>.
Relays do not publish descriptors until their ORPort and DirPort are reachable...

  • Network and provider firewalls looked correct. Nonetheless, reachability didn’t pass.

What I changed to get them to start again

  • Allowed non-root bind to 443:

    sudo setcap 'cap_net_bind_service=+ep' /usr/bin/tor

  • Made ORPort/address explicit in torrc (I tried both single-stack v4 and dual-stack):

    ORPort 0.0.0.0:443 IPv4Only
ORPort [::]:443     IPv6Only
Address <IP_ADDRESS>
SocksPort 0
RunAsDaemon 1

  • On hosts that DNAT to a private RFC1918 address, I set rp_filter to loose to stop the kernel from dropping SYNs before iptables:

    sudo sysctl -w net.ipv4.conf.all.rp_filter=2
sudo sysctl -w net.ipv4.conf.default.rp_filter=2

  • Ensured iptables has “established/related” and ORPort 443 ACCEPT rules before the final REJECT.

After these, the relays start, bind to 0.0.0.0:443 (and :: where used), external port checks succeed (443 open from the internet), and the previous reachability warning went away.

Current problem

Despite being up, traffic stays at 0 bytes. No client connections appear in Nyx. Onionoo/Relay Search visibility is inconsistent (sometimes not listed yet). I’m unsure if this is a consensus/descriptor issue, some subtle provider filtering, a hibernation/bandwidth-accounting misconfig or something else I’ve overlooked.

Environment / versions

  • Tor 0.4.8.17 (OpenSSL 3.0.13, Libevent 2.1.12)

  • Linux (systemd)

  • Multiple VPS providers (incl. Oracle Cloud & Kamatera, IONOS)

  • Some instances are behind provider DNAT to a private IP (e.g. 10.x.y.z) with a public IPv4.

Relevant torrc (current)

Nickname <NICKNAME>
ContactInfo <CONTACT>
ORPort 0.0.0.0:443 IPv4Only
# (on dual-stack hosts)
# ORPort [::]:443 IPv6Only
Address <IP_ADDRESS>
SocksPort 0
ExitPolicy reject *:*
# optional: Accounting
AccountingRule sum
AccountingMax 4.5 TBytes
RunAsDaemon 1
# ControlPort is local-only for Nyx
ControlPort 127.0.0.1:9051
CookieAuthentication 1

What I already checked

  • ss -ltnp shows Tor listening on 443 (v4 and optionally v6).

  • External checks (PowerShell Test-NetConnection <IP> -Port 443and nmap) return True.

  • tcpdump now shows SYN → SYN/ACK for inbound 443.

  • iptables INPUT has:

    • -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

    • -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT

    • final REJECT after those.

  • System clock is synced (NTP).

  • No other service on 443.

Questions

  1. What else could make a relay run with 0 B traffic after reachability succeeds?
    (e.g., waiting on Running flag/consensus, bad Address being published, family config side-effects?)

  2. Could a provider-level policy still allow TCP 443 but somehow block/shape Tor TLS in a way that results in 0 traffic?

  3. Any logs/metrics I should share beyond notice lines like “Self-testing indicates your ORPort is reachable / Publishing server descriptor”?
    (Happy to provide fingerprints, exact torrc, and more logs if helpful.)

Thanks a ton for any pointers - I feel I’m one step away but can’t spot what’s left.