How Tor bridges get distributed: BridgeDB, rdsys, Moat and the logic of scarcity
A bridge is an unlisted Tor relay: it is not published in the public relay list, so a censor has to discover it before it can be blocked. That property only holds for as long as the bridge stays hard to obtain, which makes the distribution system itself part of Tor's censorship resistance. In October 2024, the Tor Project retired BridgeDB, the system that had handed out bridges for over a decade, and completed the migration to rdsys, its next-generation distribution system. How these systems decide who gets which bridge explains a lot about why bridges still work in heavily censored networks.
From BridgeDB to rdsys
BridgeDB was released more than eleven years ago as a prototype and kept running long past its intended lifespan. According to the engineers behind the migration, it offered web-based requests, email requests and a Tor Browser API called Moat, and all three channels came under pressure: censors scraped bridge-request websites, flooded the email system to harvest addresses, and bypassed captchas by leveraging human CAPTCHA-solving services. Years of patches against these tactics turned into technical debt, so the project began developing a replacement, rdsys, around 2020. rdsys, short for resource distribution system, is deliberately broader than its predecessor. It hands out circumvention resources of many kinds: Tor bridges, Snowflake proxies, VPN endpoints, even download links for circumvention software. Architecturally it is one backend process that collects resources and several distributor processes that hand them out. The backend keeps the inventory and maps each resource to exactly one distributor; the distributor's job, as the rdsys documentation puts it, is to hand resources out smartly, present a usable interface and thwart Sybil attacks. The distribution channels
The Tor Project's support documentation is blunt about the premise: "Because bridge addresses are not public, you will need to request them yourself." Today there are several parallel channels, each with its own gatekeeping. - Moat is built into Tor Browser: users click "Request bridges" in the connection settings, solve a captcha, and the bridges are added automatically.
- The HTTPS distributor runs the bridges website, which offers a one-click "Just give me bridges!" option alongside advanced choices such as transport type or IPv6-only addresses.
- The email distributor answers messages to bridges@torproject.org, sent from a Gmail or Riseup address, with "get transport obfs4" in the body.
- The Telegram distributor serves bridges through the @GetBridgesBot, using commands like /obfs4 or /webtunnel. To tell real users apart from mass-created accounts, it weighs account history, distinguishing old accounts from freshly registered ones; the Tor Project describes this as a response to increasing censorship in Russia.
- Lox, still under development, is a privacy-preserving, reputation-based mechanism that detects blocked bridges and rewards users whose bridges remain unblocked.
There are also two non-channels worth knowing about. A Reserved pool is set aside for manual distribution to NGOs and individuals with special needs, and bridges marked None are left for their operators to distribute on their own. A freshly registered bridge shows None for roughly a day before it joins its assigned pool. Moat and the captcha trade-off
Moat deserves a closer look because it is the path most new users encounter first. The captcha was the system's way of proving a request comes from a human rather than a censor's scraper, and solving one is still the documented flow inside Tor Browser. But the Tor Project's own assessment is that captchas have become a poor deal: they are frustratingly inaccessible for people using screen readers or older devices, sometimes impossible across language barriers, and increasingly ineffective because censors employ automated tools or human solving services to walk straight through them. That is why rdsys is shifting away from captchas, and why Moat is being deprecated in favour of the Settings distributor, an API that auto-configures circumvention settings, including which bridge type to try, based on the user's country. Why scarcity is the point
Every bridge handed out is a bridge a censor could learn, so distribution is deliberately rationed rather than published. The rdsys backend only hands out resources that are known to work: the bridgestrap service tests each bridge's pluggable transports and marks them functional or dysfunctional, a separate service measures bandwidth, and every Tor bridge is re-tested once its eighteen-hour expiry timer runs out. Operators can query their own bridge's state through a public status page by fingerprint. Blocked or broken bridges are pulled out of circulation instead of being pushed at more users in the same region, and a mechanism like Lox is built specifically to detect blocked bridges and route fresh ones to the people who still need them. An open research problem
The underlying tension is old. In a 2016 paper, researchers behind the TorBricks protocol stated it plainly: current methods for distributing bridges are vulnerable to malicious users who obtain and block bridge addresses. Their proposal rationed a logarithmic budget of bridges per adversarial user, so that even with an unknown number of censor-controlled requesters, honest users could still get a working bridge after a few rounds of communication. A decade later, the general problem remains unsolved; rdsys's answer is pragmatic rather than mathematical: many small channels, each with different heuristics, so that no single scrape or flood drains the pool. For the practical counterpart to this piece, our guide to bridges in censored regions covers how to request and configure them today. The takeaway
Bridge distribution is a balancing act between reachability and scarcity. Publish too freely and censors collect the list; gate too tightly and legitimate users cannot get in. The move from BridgeDB to rdsys did not end that trade-off, but it made the system modular enough to keep trying new channels, from Telegram and Lox to location-aware defaults, as old ones erode. For censored users, the advice has not changed: request a few bridges, test them, and be ready to ask for more.
