3 Special Hostnames in Tor
8 Most of the time, Tor treats user-specified hostnames as opaque: When the
9 user connects to tor.eff.org, Tor picks an exit node and uses that node to
10 connect to "tor.eff.org". Some hostnames, however, can be used to override
11 Tor's default behavior and circuit-building rules.
13 These hostnames can be passed to Tor as the address part of a SOCKS4a or
14 SOCKS5 request. If the application is connected to Tor using an IP-only
15 method (such as SOCKS4, TransPort, or NatdPort), these hostnames can be
16 substituted for certain IP addresses using the MapAddress configuration
17 option or the MAPADDRESS control command.
21 SYNTAX: [hostname].[name-or-digest].exit
24 Hostname is a valid hostname; [name-or-digest] is either the nickname of a
25 Tor node or the hex-encoded digest of that node's public key.
27 When Tor sees an address in this format, it uses the specified hostname as
28 the exit node. If no "hostname" component is given, Tor defaults to the
29 published IPv4 address of the exit node.
31 It is valid to try to resolve hostnames, and in fact upon success Tor
32 will cache an internal mapaddress of the form
33 "www.google.com.foo.exit=64.233.161.99.foo.exit" to speed subsequent
37 www.example.com.exampletornode.exit
39 Connect to www.example.com from the node called "exampletornode."
43 Connect to the published IP address of "exampletornode" using
44 "exampletornode" as the exit.
48 SYNTAX: [digest].onion
50 The digest is the first eighty bits of a SHA1 hash of the identity key for
51 a hidden service, encoded in base32.
53 When Tor sees an address in this format, it tries to look up and connect to
54 the specified hidden service. See rend-spec.txt for full details.
58 SYNTAX: [string].noconnect
60 When Tor sees an address in this format, it immediately closes the
61 connection without attaching it to any circuit. This is useful for
62 controllers that want to test whether a given application is indeed using
63 the same instance of Tor that they're controlling.