The Tor network data provided here comes from five different sources which are explained in more detail on this page. You may either read through the entire page or jump to the type of data you're most interested in:
Each descriptor provided here contains an @type annotation using the format @type $descriptortype $major.$minor. Any tool that processes these descriptors may parse files without meta data or with an unknown descriptor type at its own risk, can safely parse files with known descriptor type and same major version number, and should not parse files with known descriptor type and higher major version number.
Relays and directory authorities publish relay descriptors, so that clients can select relays for their paths through the Tor network. All these relay descriptors are specified in the Tor directory protocol, version 3 specification document (or in the earlier protocol versions 2 or 1). This page shall give a quick overview of what relay descriptors are available.
Server descriptors contain information that relays publish about themselves. Tor clients once downloaded this information, but now they use microdescriptors instead. The server descriptors in archive contain one descriptor per file, whereas the files in recent contain all descriptors collected in an hour concatenated into a single file.
Extra-info descriptors contain relay information that Tor clients do not need in order to function. This is self-published, like server descriptors, but not downloaded by clients by default. The extra-info descriptors in archive contain one descriptor per file, whereas the files in recent contain all descriptors collected in an hour concatenated into a single file.
Though Tor relays are decentralized, the directories that track the overall network are not. These central points are called directory authorities, and every hour they publish a document called a consensus, or network status document. The consensus in turn is made up of router status entries containing flags, heuristics used for relay selection, etc.
The directory authorities exchange votes every hour to come up with a common consensus. Vote documents are by far the largest documents provided here.
The directory authorities sign their votes and the consensus with their key that they publish in a key certificate. These key certificates change once every few months, so they are only available in the archive.
Tor clients used to download all server descriptors of active relays, but now they only download the smaller microdescriptors which are derived from server descriptors. The microdescriptor consensus lists all active relays and references their currently used microdescriptor. The tarballs in archive contain both microdescriptor consensuses and referenced microdescriptors together.
Microdescriptors are minimalistic documents that just includes the information necessary for Tor clients to work. The tarballs in archive contain both microdescriptor consensuses and referenced microdescriptors together. The microdescriptors in archive contain one descriptor per file, whereas the files in recent contain all descriptors collected in an hour concatenated into a single file.
Version 2 network statuses have been published by the directory authorities before consensuses have been introduced. In contrast to consensuses, each directory authority published their own authoritative view on the network, and clients combined these documents locally. We stopped archiving version 2 network statuses in 2012.
The first directory protocol version combined the list of active relays with server descriptors in a single directory document. We stopped archiving version 1 directories in 2007.
Bridges and the bridge authority publish bridge descriptors that are used by censored clients to connect to the Tor network. We cannot, however, make bridge descriptors available as we do with relay descriptors, because that would defeat the purpose of making bridges hard to enumerate for censors. We therefore sanitize bridge descriptors by removing all potentially identifying information and publish sanitized versions here. The sanitizing steps are as follows:
Sanitized bridge network statuses are similar to version 2 relay network statuses, but with only a published line in the header and without any lines in the footer. The tarballs in archive contain all bridge descriptors of a given month, not just network statuses.
Bridge server descriptors follow the same format as relay server descriptors, except for the sanitizing steps described above. The tarballs in archive contain all bridge descriptors of a given month, not just server descriptors. These tarballs contain one descriptor per file, whereas the files in recent contain all descriptors collected in an hour concatenated into a single file to reduce the number of files.
There was supposed to be a newer version of this document that indicates added ntor-onion-key lines, but due to a mistake only the version number of sanitized bridge extra-info descriptors was raised. As a result, there may be sanitized bridge server descriptors with and without those lines.
Bridge extra-info descriptors follow the same format as relay extra-info descriptors, except for the sanitizing steps described above. The format has changed over time to accomodate changes to the sanitizing process, with earlier versions being:
The tarballs in archive contain all bridge descriptors of a given month, not just extra-info descriptors. These tarballs contain one descriptor per file, whereas the files in recent contain all descriptors collected in an hour concatenated into a single file to reduce the number of files.
The bridge distribution service BridgeDB publishes bridge pool assignments describing which bridges it has assigned to which distribution pool. BridgeDB receives bridge network statuses from the bridge authority, assigns these bridges to persistent distribution rings, and hands them out to bridge users. BridgeDB periodically dumps the list of running bridges with information about the rings, subrings, and file buckets to which they are assigned to a local file. The sanitized versions of these lists containing SHA-1 hashes of bridge fingerprints instead of the original fingerprints are available for statistical analysis.
The document below shows a BridgeDB pool assignment file from March 13, 2011. Every such file begins with a line containing the timestamp when BridgeDB wrote this file. Subsequent lines start with the SHA-1 hash of a bridge fingerprint, followed by ring, subring, and/or file bucket information. There are currently three distributor ring types in BridgeDB:
bridge-pool-assignment 2011-03-13 14:38:03 00b834117566035736fc6bd4ece950eace8e057a unallocated 00e923e7a8d87d28954fee7503e480f3a03ce4ee email port=443 flag=stable 0103bb5b00ad3102b2dbafe9ce709a0a7c1060e4 https ring=2 port=443 flag=stable [...]
As of December 8, 2014, bridge pool assignment files are no longer archived.
The exit list service TorDNSEL publishes exit lists containing the IP addresses of relays that it found when exiting through them.
Tor Check makes the list of known exits and corresponding exit IP addresses available in a specific format. The document below shows an entry of the exit list written on December 28, 2010 at 15:21:44 UTC. This entry means that the relay with fingerprint 63BA.. which published a descriptor at 07:35:55 and was contained in a version 2 network status from 08:10:11 uses two different IP addresses for exiting. The first address 184.108.40.206 was found in a test performed at 07:10:30. When looking at the corresponding server descriptor, one finds that this is also the IP address on which the relay accepts connections from inside the Tor network. A second test performed at 10:35:30 reveals that the relay also uses IP address 220.127.116.11 for exiting.
ExitNode 63BA28370F543D175173E414D5450590D73E22DC Published 2010-12-28 07:35:55 LastStatus 2010-12-28 08:10:11 ExitAddress 18.104.22.168 2010-12-28 07:10:30 ExitAddress 22.214.171.124 2010-12-28 10:35:30
The performance measurement service Torperf publishes performance data from making simple HTTP requests over the Tor network. Torperf uses a trivial SOCKS client to download files of various sizes over the Tor network and notes how long substeps take.
A Torperf results file contains a single line per Torperf run with key=value pairs. Such a result line is sufficient to learn about 1) the Tor and Torperf configuration, 2) measurement results, and 3) additional information that might help explain the results. Known keys are explained below.
The files in recent accumulate all new Torperf measurements of a given day, which means that they may change throughout the day. This is different from all other files in the recent directory which do not change once they are written.