The Tor bridges we run

What a bridge is, and what it is not

A bridge is an unlisted entry point into the Tor network. Tor's relay list is public by design, so censors download it and block every address on it. Bridges are the countermeasure: entry points deliberately kept off that list and handed out in small numbers, so blocking them requires finding them first. obfs4 is a pluggable transport that makes the connection look like random bytes rather than like Tor, so simple protocol fingerprinting does not catch it.

A bridge is not an exit. Traffic leaves the Tor network somewhere else entirely, through relays run by other people who chose that role. Our addresses never appear as the origin of anyone's browsing, and we never see a destination. The configuration sets ExitRelay 0 and ExitPolicy reject *:* — two directives that say the same thing, because either one alone is easy to lose in a later edit.

What a bridge operator can see is the address of the machine connecting to it. That is not a confession; it is structural. Something has to be the first hop, and the first hop necessarily sees where the connection came from. Tor's design assumes it and protects the user by ensuring the first hop is the only party that knows it and knows nothing about the destination. We see no destination and no content, and we retain nothing about who connected.

These bridges are not an input to the censorship dataset. Nothing a bridge user does becomes a row in the index, a training sample, or a measurement. They are also not a product: no signup, no account, no support channel, and no relationship between Voidly and anyone whose traffic crosses them. Most people using a bridge got it from the Tor Project's own distribution system and have never heard of us. That is the correct arrangement and we would not change it if we could.

What Tor's records say

Snapshot of onionoo.torproject.org, the Tor Project's public API, taken when this page was built. Onionoo's own publication stamp: 2026-08-03 03:44:31. Nothing below is typed in by hand.

Notes on reading that table honestly, because each one is a place a less careful page would mislead you.

• The volume rows are not the whole fleet. Tor holds a bandwidth history for 1 of the 8 bridges it lists under our name. A bridge that was listed in the last day or so has published no history yet and contributes exactly nothing to the totals above — not a small amount, nothing. Read those rows as a floor on what the listed bridges carried, never as a fleet total.
• The period is the one printed, not a round number. Onionoo files these values under a bucket it calls 6_months, and quoting that label would be the easy mistake — the series actually begins 27 March 2026. Today that is also the whole life of the bridges so far. It is a rolling window, so it will eventually stop reaching back that far; the dates in the table come from the window itself and will move on their own when it does.
• Do not add the two volume rows. Sent and received are the same relayed traffic counted on the way in and on the way out, which is why they sit within a couple of per cent of each other. Summing them into a bigger headline would be double-counting. We are naming the number we chose not to print.
• “Days Tor holds a figure for” is not an uptime claim. It means a value was published for that day, not that the service was continuously available within it. The stricter measure lives in Onionoo's uptime document, which is linked below.
• 12 of those days recorded no outbound traffic at all. A newly listed bridge is handed out gradually, and there is a lag between appearing in the directory and reaching anyone. Note the resolution: these values are scaled integers, so a recorded zero means every bridge reporting that day moved less than its own rounding step, which together comes to roughly 34.6 MB — not literally nothing. Anyone standing a bridge up should expect the same and not read early silence as failure.
• Compare per bridge-day, because the fleet changes size. The last 31 days averaged about 17.2 GB sent per bridge per day, against 12.4 GB across the longer period. The obvious comparison — total gigabytes a day, then and now — is the one we are not printing: adding bridges raises it on its own, so a page that ran that comparison and called the result rising traffic would be reporting its own purchase order as demand. Both figures here divide by bridge-days that actually recorded traffic. We are not attributing what movement remains to anything.

Which of these numbers Tor actually vouches for

It would be an easy sentence to write that none of this comes from us. It would also be false, and false in the one place this page cannot afford it. Tor operates no bandwidth authority for bridges. There are three different kinds of claim in the table above and they deserve different amounts of your trust.

• Attested by Tor. Whether a bridge is running, its flags, when it was first and last seen, and which distributor hands it out. Tor's bridge authority reachability-tests for these. They are third-party statements about our infrastructure and we cannot manufacture them.
• Self-reported by us, archived by Tor. Every volume figure. Our own daemon writes its bandwidth history into an extra-info descriptor, signs it and publishes it; Onionoo stores and re-serves what it was given. What that still buys you is real but narrower than independence: the figures were published contemporaneously, they sit in an archive we do not control, and we cannot go back and edit or delete them. That is tamper-evidence and independent custody. It is not independent measurement, and anyone who tells you otherwise about any bridge operator's bandwidth is wrong.
• Unverified entirely. That these bridges are ours. Nickname and ContactInfo are free text an operator writes into their own configuration; Tor republishes both and validates neither, and nicknames are neither unique nor reserved — the two commonest names on the bridge network are each shared by well over a hundred running bridges. The snapshot only counts a bridge if its nickname carries our prefix and its ContactInfo names voidly.ai, and volume is joined by fingerprint so an unconfirmed bridge can never be summed into our totals. That raises the cost of someone else landing in these figures. It does not eliminate it. If the count here ever jumps without a word from us, suspect that before you suspect the rest of the page.

The rule this page follows throughout: figures Tor publishes appear in the table; claims that are only ours appear in prose, labelled as ours. Nothing of the second kind is presented as a measurement.

How to check it

No API key, no account. Four requests to a host we do not run:

https://onionoo.torproject.org/details?search=VoidlyBridge&type=bridge
https://onionoo.torproject.org/bandwidth?search=VoidlyBridge&type=bridge
https://onionoo.torproject.org/uptime?search=VoidlyBridge&type=bridge
https://onionoo.torproject.org/clients?search=VoidlyBridge&type=bridge

The volume totals are not sitting in the JSON ready to read; you have to do the arithmetic. Each history object holds a values array of scaled integers, a factor to multiply by, and an interval in seconds. Multiply, skip the nulls, sum, divide by 1e9 for gigabytes:

import json, urllib.request
u = "https://onionoo.torproject.org/bandwidth?search=VoidlyBridge&type=bridge"
b = json.load(urllib.request.urlopen(u))["bridges"][0]
h = b["write_history"]["6_months"]
v = [x for x in h["values"] if x is not None]
print(sum(v) * h["factor"] * h["interval"] / 1e9, "GB sent")
print(h["first"], "->", h["last"], len(v), "daily values")

For the worldwide figure, request https://onionoo.torproject.org/summary?type=bridge&running=true&limit=1 and add bridges_truncated to the one bridge the response returns.

Onionoo lags by a few hours and occasionally longer, and this page is regenerated when the site is built rather than when you load it. So a difference of a few gigabytes means this page is older than your request and nothing more. The build stamp is at the bottom; if it is old, so are the numbers. If our figures and Tor's disagree, Tor is right. That is what it means to publish against a record you do not control, and it is the only reason the exercise is worth anything.

The number that is missing

We can read our own bridges' aggregate client statistics. We are not publishing them, and that is a decision rather than an oversight. Two reasons, in order of weight.

A client count is operationally useful to a censor. It ranks bridges by how many people a block would affect, and then it confirms the block worked by falling to zero. Publishing it hands over both halves. On 2 August 2026 we removed a machine-readable field of our own that carried exactly that quantity; putting the same number back as prose would restore the disclosure in a slower, less convenient form. Slower is not safe.

And you could not check it. Onionoo publishes per-bridge client estimates for bridges that report them. For ours it returns the bridge with no client periods at all — not an error and not us withholding something, and you can confirm that emptiness at the clients URL above. Any figure we printed would be our reading of our own instrument.

Declined for the same reasons: a per-country breakdown, which would be a map of who is evading censorship where and is not ours to publish at any confidence; and any derived proxy — gigabytes per user, concurrent-session estimates, “enough traffic for N people” — which would launder the same number back in through arithmetic.

One honest correction to our own argument: the bandwidth figures are also our own instrument's reading, as set out above. The difference between them and the client count is publication and custody, not kind. It is the first reason, not the second, that decides this.

What we do not publish, and why

No addresses, hostnames, fingerprints, ports, cities, networks or providers. Not for any bridge Voidly runs, not on request, and nothing from which they can be derived. A bridge works by being difficult to enumerate; publishing one ends its usefulness the same afternoon and disconnects every person currently relying on it. The outcome is not “less privacy”, it is “those users lose their connection”.

This is not a Voidly policy but Tor's, applied to everyone. Look at the or_addresses field in the details response and you will find an address in private, non-routable space that belongs to no one and routes nowhere: Onionoo replaces every bridge's real address with a placeholder before publishing. The one field a censor would want is the one field the transparency API deliberately does not contain — for every running bridge, not just ours. Nicknames appear here only because Tor already publishes them, and they are chosen to encode nothing about where a bridge is.

The same reasoning rules out the obvious product. A registry — sign up, claim your bridge, get a badge, appear on a leaderboard — would look like community and function as a target list with an API in front of it. So there is no registry, no form, and no way to tell us about your bridge.

Two disclosures of our own were removed on 2 August 2026: a line of public copy, and a machine-readable status field. Neither contained an address. Both narrowed the search for one. We are not describing them further here, which is the same reason they are gone.

It is also why these numbers are fetched from Tor when the site is built and then served as a static file. There is no Voidly endpoint that answers questions about Voidly bridges, and there will not be: building one would rebuild the oracle we just removed.

The front door we do publish

What we do not publish is a bridge address. What we do publish is this one:

yzhdov45xn6op2obddwbrltmx22j5cukbpragaul24g3brlnet6kfrad.onion

That is Veil, our messenger — not this observatory. The two rules are exact opposites, and it is worth being explicit about why. A bridge works by being hard to enumerate, so publishing one ends its usefulness the same afternoon and disconnects everyone currently on it. An onion address works by being reachable, and one that nobody can find has no users — which is the state this one was in until today. Secrecy is the entire mechanism of the first and the failure mode of the second.

If you open msg.voidly.ai in Tor Browser you do not need to copy anything. A purple .onion available button appears in the address bar; one click moves you across. That button is driven by an Onion-Location header the site now sends on every page except the invite links — an invite carries its key material in the part of the URL that a browser never sends to a server, and following the button would arrive with that key stripped, so those pages deliberately do not offer it.

What it gives you. Your ISP and the Tor exit node see that you are using Tor, not that you are contacting Veil — msg.voidly.ai never appears in a DNS lookup or a TLS handshake. It also keeps working if the domain name itself is taken away.

What it does not give you, and we want to be plain about this: independence from Cloudflare. The onion serves the app from our own machine, but it reverse-proxies the API to api.voidly.ai, which is a Cloudflare Worker. Send a request to the onion's /health and a CF-RAY header comes back — Cloudflare is still in the path, and anyone telling you an onion address alone removes that dependency is selling something. Nor does it help someone whose Tor connection cannot be established in the first place. That is why bridges, not onions, are the larger part of this page.

Use Tor Browser, not Firefox with a proxy. An onion service is served over plain HTTP, and only Tor Browser treats a .onion origin as a secure context. Without that the Web Crypto API is unavailable and Veil cannot encrypt anything — you get a refusal, not a quiet downgrade to something weaker.

Your account does not travel with you. Veil keeps your keys and message history in browser storage, which belongs to the origin that created it. msg.voidly.ai and the onion are two different origins, so the onion will meet you as a brand-new user. If you already have an account, export it first — Settings, then encrypted backup — and import it on the other side. Tor Browser can be configured to move you to onion services automatically, with no click at all, so do the export before you turn that on.

Where this count comes from, and why it can lag

The figure at the top of this page is whatever Tor's directory currently reports, not what we claim to operate. Those are different quantities and they routinely disagree. A bridge reaches Tor's bridge authority within minutes of starting, but Onionoo republishes on its own schedule — a couple of hours, sometimes longer. Anything we started inside that window is real and absent from the number above.

We are not printing the other number. Not here, not as prose, not rounded, not as “more than Tor lists”. It would be true and it would be uncheckable, and this page is built on the premise that the second property cancels the first — a figure only we can assert is worth less than one you can refute. It would also need a human to remember to change it, and a hand-maintained count on a page whose whole claim is that nothing is typed in by hand is a defect waiting for a quiet week. This section previously carried exactly such a sentence. It went stale, as that kind of sentence does, and it is gone.

So the count moves on its own, and nobody edits this page to move it. What that costs you is that this page understates during the lag. What it buys you is that every number here is one you can go and check against a host we do not run. If the count sits still for days while we are plainly saying elsewhere that we started something, do not conclude Onionoo is slow — conclude that something we started is not reaching the Tor network, which is a failure on our side and the thing this section is here to let you catch.

Why a censorship observatory runs bridges at all

Measurement and circumvention are different jobs, and blurring them is how measurement projects lose their credibility. So it is worth being exact about the reasoning rather than calling it a mission.

Because measuring censorship does not undo it. The index describes the problem in increasing detail and does not, by itself, help one person reach one website. A bridge is the smallest concrete thing an operation like this can do about what it documents.

Because our central limitation is not fixable with more measurement. Voidly publishes a page about where we cannot see. That gap is not random: it is widest exactly where the network is most repressive, because measurement there depends on somebody inside taking a personal risk.

And there is an incentive worth naming. An organisation whose value depends on measuring censorship has a quiet interest in there being censorship to measure. Spending a little capacity on the other side of that ledger is a small, honest correction, and we would rather name the incentive than pretend we are above it.

The honest limit: none of this makes the censorship data better. The bridges produce no measurements, are not instrumented, and will not be. If running them ever started improving our numbers, that would be a reason to stop rather than a feature. They do nothing to close the coverage gaps above.

If you need a bridge, or want to run one

• Do not ask us for a bridge. Request one through Tor Browser's built-in flow or at bridges.torproject.org, which hands them out in small numbers specifically to make bulk enumeration expensive. If we handed ours to everyone who asked, we would be doing the censor's collection work.
• Running one is the genuinely useful contribution — more bridges on more networks is worth considerably more than more bandwidth on ours. Tor's own bridge guide is the canonical source. You need a stable public address, reachable ports and continuous uptime; on a home connection behind NAT the setup fails silently, so run Snowflake instead — it is built for exactly that case and it is one click.
• Do not publish your bridge's address anywhere. That includes to us. There is nowhere on this site to send it, on purpose.
• Cite the source, not this page. For any figure here the citable URL is the Onionoo query. We are a redundant step and you should feel free to skip us. Numbers move, so quote the date.