I’m running a bridge with the following ID:
https://bridges.torproject.org/status?id=744DA6E2E2BCB93999C8B16C1C185BA06DFFA447
The bridge had been running successfully for about 60 days, then hit an ISP‑assigned external IP change. For roughly 5 days after that change, the bridge kept running but was advertising the old IP, so it became unreachable while Tor itself stayed up.
After that, I:
Registered a DDNS hostname.
Changed Address in torrc from the hardcoded IP to that DDNS name.
Restarted Tor, so the bridge is now publishing under the same fingerprint but with the new Address.
Since that restart, according to logs and what I can see in nyx, the bridge is working:
It has been up continuously for over 3 days.
It often has 20–25 open circuits, largely hs_vanguards and conflux‑linked, and logs show normal traffic and descriptor‑publishing activity.
The ORPort and obfs4 transport are reachable; Tor’s own TCP Reachability Check at https://bridges.torproject.org/scan/scan?address=<my_ip>&port=38137 consistently reports success.
However, the status page at the ID URL has never shown the bridge as “functional” since the restart. The obfs4‑IPv4 line is always marked as “dysfunctional” with something like “timed out waiting for bridge descriptor,” even though the bridge is demonstrably reachable and actively serving clients.
Is this something that would fall under a bug or stale state in the bridge‑status / rdsys / metrics side, or is there a configuration change I should make on the bridge itself? I’m happy to provide torrc snippets or log excerpts if that helps narrow it down.