tor-webwml.git

@@ -61,9 +61,9 @@

           {'url'  => 'docs/running-a-mirror',

            'txt'  => 'ضبط مرآة',

           },

-#          {'url'  => 'docs/tor-manual',

-#           'txt'  => 'تور- دليل الإصدارة الثابتة',

-#          },

+          {'url'  => 'docs/tor-manual',

+           'txt'  => 'تور- دليل الإصدارة الثابتة',

+          },

           {'url'  => 'docs/tor-manual-dev',

            'txt'  => 'تور- دليل الإصدارة ألفا',

           },

@@ -61,9 +61,9 @@

           {'url'  => 'docs/running-a-mirror',

            'txt'  => 'Configuring a Mirror',

           },

-#          {'url'  => 'docs/tor-manual',

-#           'txt'  => 'Tor -stable Manual',

-#          },

+          {'url'  => 'docs/tor-manual',

+           'txt'  => 'Tor -stable Manual',

+          },

           {'url'  => 'docs/tor-manual-dev',

            'txt'  => 'Tor -alpha Manual',

           },

@@ -9,15 +9,2314 @@

   <div id="breadcrumbs">

     <a href="<page index>">Home &raquo; </a>

     <a href="<page docs/documentation>">Documentation &raquo; </a>

-    <a href="<page docs/tor-doc-osx>">Tor Dev Manual</a>

+    <a href="<page docs/tor-doc-osx>">Tor Manual</a>

   </div>

   <div id="maincol">

-    <:

-    	die "Missing git clone at $(TORGIT)" unless -d "$(TORGIT)";

-    	my $man = `GIT_DIR=$(TORGIT) git show $(STABLETAG):doc/tor.1.txt | asciidoc -d manpage -s -o - -`;

-    	die "No manpage because of asciidoc error or file not available from git" unless $man;

-    	print $man;

-    :>

+	<h2 id="_synopsis">SYNOPSIS</h2>

+	<div class="sectionbody">

+			<div class="paragraph"><p><strong>tor</strong> [<em>OPTION</em> <em>value</em>]&#8230;</p>

+			</div>

+	</div>

+		<h2 id="_description">DESCRIPTION</h2>

+		<div class="sectionbody">

+			<div class="paragraph"><p><em>tor</em> is a connection-oriented anonymizing communication

+			service. Users choose a source-routed path through a set of nodes, and

+			negotiate a "virtual circuit" through the network, in which each node 

+			knows its predecessor and successor, but no others. Traffic flowing down 

+			the circuit is unwrapped by a symmetric key at each node, which reveals

+			the downstream node.<br /></p></div>

+			

+			<div class="paragraph"><p>Basically <em>tor</em> provides a distributed network of servers ("onion routers").

+			Users bounce their TCP streams — web traffic, ftp, ssh, etc — around the

+			routers, and recipients, observers, and even the routers themselves have 

+			difficulty tracking the source of the stream.</p></div>

+		</div>

+		<h2 id="_options">OPTIONS</h2>

+		<div class="sectionbody">

+			<div class="dlist"><dl>

+				<dt class="hdlist1">

+					<strong>-h</strong>, <strong>-help</strong>

+				</dt>

+				<dd>

+					<p>

+					    Display a short help message and exit.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>-f</strong> <em>FILE</em>

+				</dt>

+				<dd>

+					<p>

+					    FILE contains further "option value" pairs. (Default: @CONFDIR@/torrc)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--hash-password</strong>

+				</dt>

+				<dd>

+					<p>

+					    Generates a hashed password for control port access.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--list-fingerprint</strong>

+				</dt>

+				<dd>

+					<p>

+					    Generate your keys and output your nickname and fingerprint.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--verify-config</strong>

+				</dt>

+				<dd>

+					<p>

+					    Verify the configuration file is valid.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--nt-service</strong>

+				</dt>

+				<dd>

+					<p>

+					    <strong>--service [install|remove|start|stop]</strong> Manage the Tor Windows

+					    NT/2000/XP service. Current instructions can be found at

+					    <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#WinNTService">https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#WinNTService</a>

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--list-torrc-options</strong>

+				</dt>

+				<dd>

+					<p>

+					    List all valid options.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--version</strong>

+				</dt>

+				<dd>

+					<p>

+					    Display Tor version and exit.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>--quiet</strong>

+				</dt>

+				<dd>

+					<p>

+					    Do not start Tor with a console log unless explicitly requested to do so.

+					    (By default, Tor starts out logging messages at level "notice" or higher to

+					    the console, until it has parsed its configuration.)

+					</p>

+				</dd>

+				</dl>

+			</div>

+			<div class="paragraph">

+				<p>Other options can be specified either on the command-line (--option

+    				value), or in the configuration file (option value or option "value").

+				Options are case-insensitive. C-style escaped characters are allowed inside

+				quoted values. Options on the command line take precedence over

+    				options found in the configuration file, except indicated otherwise. To

+    				split one configuration entry into multiple lines, use a single \ before

+    				the end of the line. Comments can be used in such multiline entries, but

+    				they must start at the beginning of a line.</p>

+			</div>

+			<div class="dlist"><dl>

+				<dt class="hdlist1">

+					<strong>BandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>

+				</dt>

+				<dd>

+					<p>

+					    A token bucket limits the average incoming bandwidth usage on this node to

+					    the specified number of bytes per second, and the average outgoing

+					    bandwidth usage to that same value. If you want to run a relay in the

+					    public network, this needs to be <em>at the very least</em> 20 KB (that is,

+					    20480 bytes). (Default: 5 MB)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>BandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>

+				</dt>

+				<dd>

+					<p>

+					    Limit the maximum token bucket size (also known as the burst) to the given

+				    	    number of bytes in each direction. (Default: 10 MB)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>MaxAdvertisedBandwidth</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>

+				</dt>

+				<dd>

+					<p>

+					    If set, we will not advertise more than this amount of bandwidth for our

+					    BandwidthRate. Server operators who want to reduce the number of clients

+					    who ask to build circuits through them (since this is proportional to

+					    advertised bandwidth rate) can thus reduce the CPU demands on their server

+					    without impacting network performance.

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>RelayBandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>

+				</dt>

+				<dd>

+					<p>

+					    If not 0, a separate token bucket limits the average incoming bandwidth

+					    usage for _relayed traffic_ on this node to the specified number of bytes

+					    per second, and the average outgoing bandwidth usage to that same value.

+					    Relayed traffic currently is calculated to include answers to directory

+					    requests, but that may change in future versions. (Default: 0)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>RelayBandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>

+				</dt>

+				<dd>

+					<p>

+					    If not 0, limit the maximum token bucket size (also known as the burst) for

+					    _relayed traffic_ to the given number of bytes in each direction.

+					    (Default: 0)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>ConnLimit</strong> <em>NUM</em>

+				</dt>

+				<dd>

+					<p>

+					    The minimum number of file descriptors that must be available to the Tor

+					    process before it will start. Tor will ask the OS for as many file

+					    descriptors as the OS will allow (you can find this by "ulimit -H -n").

+					    If this number is less than ConnLimit, then Tor will refuse to start.<br />

+					    <br />

+					    You probably don’t need to adjust this. It has no effect on Windows

+					    since that platform lacks getrlimit(). (Default: 1000)

+					</p>

+				</dd>

+				<dt class="hdlist1">

+					<strong>ConstrainedSockets</strong> <strong>0</strong>|<strong>1</strong>

+				</dt>

+				<dd>

+					<p>

+					    If set, Tor will tell the kernel to attempt to shrink the buffers for all

+					    sockets to the size specified in <strong>ConstrainedSockSize</strong>. This is useful for

+					    virtual servers and other environments where system level TCP buffers may

+					    be limited. If you’re on a virtual server, and you encounter the "Error

+					    creating network socket: No buffer space available" message, you are

+					    likely experiencing this problem.<br />

+					    <br />

+					    The preferred solution is to have the admin increase the buffer pool for

+					    the host itself via /proc/sys/net/ipv4/tcp_mem or equivalent facility;

+					    this configuration option is a second-resort.<br />

+					    <br />

+					    The DirPort option should also not be used if TCP buffers are scarce. The

+					    cached directory requests consume additional sockets which exacerbates

+					    the problem.<br />

+					    <br />

+					    You should <strong>not</strong> enable this feature unless you encounter the "no buffer

+					    space available" issue. Reducing the TCP buffers affects window size for

+					    the TCP stream and will reduce throughput in proportion to round trip

+					    time on long paths. (Default: 0.)

+					</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>ConstrainedSockSize</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>

+					</dt>

+					<dd>

+						<p>

+						    When <strong>ConstrainedSockets</strong> is enabled the receive and transmit buffers for

+						    all sockets will be set to this limit. Must be a value between 2048 and

+						    262144, in 1024 byte increments. Default of 8192 is recommended.

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>ControlPort</strong> <em>Port</em>

+					</dt>

+					<dd>

+						<p>

+						    If set, Tor will accept connections on this port and allow those

+						    connections to control the Tor process using the Tor Control Protocol

+						    (described in control-spec.txt). Note: unless you also specify one of

+						    <strong>HashedControlPassword</strong> or <strong>CookieAuthentication</strong>, setting this option will

+						    cause Tor to allow any process on the local host to control it. This

+						    option is required for many Tor controllers; most use the value of 9051.

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>ControlListenAddress</strong> <em>IP</em>[:<em>PORT</em>]

+					</dt>

+					<dd>

+						<p>

+						    Bind the controller listener to this address. If you specify a port, bind

+						    to this port rather than the one specified in ControlPort. We strongly

+						    recommend that you leave this alone unless you know what you’re doing,

+						    since giving attackers access to your control listener is really

+						    dangerous. (Default: 127.0.0.1) This directive can be specified multiple

+						    times to bind to multiple addresses/ports.

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>ControlSocket</strong> <em>Path</em>

+					</dt>

+					<dd>

+						<p>

+						    Like ControlPort, but listens on a Unix domain socket, rather than a TCP

+						    socket. (Unix and Unix-like systems only.)

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>HashedControlPassword</strong> <em>hashed_password</em>

+					</dt>

+					<dd>

+						<p>

+						    Don’t allow any connections on the control port except when the other

+						    process knows the password whose one-way hash is <em>hashed_password</em>. You

+						    can compute the hash of a password by running "tor --hash-password

+						    <em>password</em>". You can provide several acceptable passwords by using more

+						    than one HashedControlPassword line.

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>CookieAuthentication</strong> <strong>0</strong>|<strong>1</strong>

+					</dt>

+					<dd>

+						<p>

+						    If this option is set to 1, don’t allow any connections on the control port

+						    except when the connecting process knows the contents of a file named

+						    "control_auth_cookie", which Tor will create in its data directory. This

+						    authentication method should only be used on systems with good filesystem

+						    security. (Default: 0)

+						</p>

+					</dd>

+					<dt class="hdlist1">

+						<strong>CookieAuthFile</strong> <em>Path</em>

+					</dt>

+					<dd>

+						<p>

+						    If set, this option overrides the default location and file name

+						    for Tor’s cookie file. (See CookieAuthentication above.)

+						</p>

+					</dd>

+					<dt class="hdlist1">

+<strong>CookieAuthFileGroupReadable</strong> <strong>0</strong>|<strong>1</strong>|<em>Groupname</em>

+</dt>

+<dd>

+<p>

+    If this option is set to 0, don’t allow the filesystem group to read the

+    cookie file. If the option is set to 1, make the cookie file readable by

+    the default GID. [Making the file readable by other groups is not yet

+    implemented; let us know if you need this for some reason.] (Default: 0).

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>DataDirectory</strong> <em>DIR</em>

+</dt>

+<dd>

+<p>

+    Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>DirServer</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em>

+</dt>

+<dd>

+<p>

+    Use a nonstandard authoritative directory server at the provided address

+    and port, with the specified key fingerprint. This option can be repeated

+    many times, for multiple authoritative directory servers. Flags are

+    separated by spaces, and determine what kind of an authority this directory

+    is. By default, every authority is authoritative for current ("v2")-style

+    directories, unless the "no-v2" flag is given. If the "v1" flags is

+    provided, Tor will use this server as an authority for old-style (v1)

+    directories as well. (Only directory mirrors care about this.) Tor will

+    use this server as an authority for hidden service information if the "hs"

+    flag is set, or if the "v1" flag is set and the "no-hs" flag is <strong>not</strong> set.

+    Tor will use this authority as a bridge authoritative directory if the

+    "bridge" flag is set. If a flag "orport=<strong>port</strong>" is given, Tor will use the

+    given port when opening encrypted tunnels to the dirserver. Lastly, if a

+    flag "v3ident=<strong>fp</strong>" is given, the dirserver is a v3 directory authority

+    whose v3 long-term signing key has the fingerprint <strong>fp</strong>.<br />

+<br />

+    If no <strong>dirserver</strong> line is given, Tor will use the default directory

+    servers. NOTE: this option is intended for setting up a private Tor

+    network with its own directory authorities. If you use it, you will be

+    distinguishable from other users, because you won’t believe the same

+    authorities they do.

+</p>

+</dd>

+</dl></div>

+<div class="paragraph"><p><strong>AlternateDirAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em><br /></p></div>

+<div class="paragraph"><p><strong>AlternateHSAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em><br /></p></div>

+<div class="dlist"><dl>

+<dt class="hdlist1">

+<strong>AlternateBridgeAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em> fingerprint</em>

+</dt>

+<dd>

+<p>

+    As DirServer, but replaces less of the default directory authorities. Using

+    AlternateDirAuthority replaces the default Tor directory authorities, but

+    leaves the hidden service authorities and bridge authorities in place.

+    Similarly, Using AlternateHSAuthority replaces the default hidden service

+    authorities, but not the directory or bridge authorities.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FetchDirInfoEarly</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If set to 1, Tor will always fetch directory information like other

+    directory caches, even if you don’t meet the normal criteria for fetching

+    early. Normal users should leave it off. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FetchHidServDescriptors</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If set to 0, Tor will never fetch any hidden service descriptors from the

+    rendezvous directories. This option is only useful if you’re using a Tor

+    controller that handles hidden service fetches for you. (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FetchServerDescriptors</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If set to 0, Tor will never fetch any network status summaries or server

+    descriptors from the directory servers. This option is only useful if

+    you’re using a Tor controller that handles directory fetches for you.

+    (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FetchUselessDescriptors</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If set to 1, Tor will fetch every non-obsolete descriptor from the

+    authorities that it hears about. Otherwise, it will avoid fetching useless

+    descriptors, for example for routers that are not running. This option is

+    useful if you’re using the contributed "exitlist" script to enumerate Tor

+    nodes that exit to certain addresses. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HTTPProxy</strong> <em>host</em>[:<em>port</em>]

+</dt>

+<dd>

+<p>

+    Tor will make all its directory requests through this host:port (or host:80

+    if port is not specified), rather than connecting directly to any directory

+    servers.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HTTPProxyAuthenticator</strong> <em>username:password</em>

+</dt>

+<dd>

+<p>

+    If defined, Tor will use this username:password for Basic HTTP proxy

+    authentication, as in RFC 2617. This is currently the only form of HTTP

+    proxy authentication that Tor supports; feel free to submit a patch if you

+    want it to support others.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HTTPSProxy</strong> <em>host</em>[:<em>port</em>]

+</dt>

+<dd>

+<p>

+    Tor will make all its OR (SSL) connections through this host:port (or

+    host:443 if port is not specified), via HTTP CONNECT rather than connecting

+    directly to servers. You may want to set <strong>FascistFirewall</strong> to restrict

+    the set of ports you might try to connect to, if your HTTPS proxy only

+    allows connecting to certain ports.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HTTPSProxyAuthenticator</strong> <em>username:password</em>

+</dt>

+<dd>

+<p>

+    If defined, Tor will use this username:password for Basic HTTPS proxy

+    authentication, as in RFC 2617. This is currently the only form of HTTPS

+    proxy authentication that Tor supports; feel free to submit a patch if you

+    want it to support others.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>KeepalivePeriod</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    To keep firewalls from expiring connections, send a padding keepalive cell

+    every NUM seconds on open connections that are in use. If the connection

+    has no open circuits, it will instead be closed after NUM seconds of

+    idleness. (Default: 5 minutes)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>stderr</strong>|<strong>stdout</strong>|<strong>syslog</strong>

+</dt>

+<dd>

+<p>

+    Send all messages between <em>minSeverity</em> and <em>maxSeverity</em> to the standard

+    output stream, the standard error stream, or to the system log. (The

+    "syslog" value is only supported on Unix.) Recognized severity levels are

+    debug, info, notice, warn, and err. We advise using "notice" in most cases,

+    since anything more verbose may provide sensitive information to an

+    attacker who obtains the logs. If only one severity level is given, all

+    messages of that level or higher will be sent to the listed destination.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>file</strong> <em>FILENAME</em>

+</dt>

+<dd>

+<p>

+    As above, but send log messages to the listed filename. The

+    "Log" option may appear more than once in a configuration file.

+    Messages are sent to all the logs that match their severity

+    level.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>OutboundBindAddress</strong> <em>IP</em>

+</dt>

+<dd>

+<p>

+    Make all outbound connections originate from the IP address specified. This

+    is only useful when you have multiple network interfaces, and you want all

+    of Tor’s outgoing connections to use a single one. This setting will be

+    ignored for connections to the loopback addresses (127.0.0.0/8 and ::1).

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>PidFile</strong> <em>FILE</em>

+</dt>

+<dd>

+<p>

+    On startup, write our PID to FILE. On clean shutdown, remove

+    FILE.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ProtocolWarnings</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor will log with severity 'warn' various cases of other parties not

+    following the Tor specification. Otherwise, they are logged with severity

+    'info'. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>RunAsDaemon</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor forks and daemonizes to the background. This option has no effect

+    on Windows; instead you should use the --service command-line option.

+    (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SafeLogging</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    Tor can scrub potentially sensitive strings from log messages (e.g.

+    addresses) by replacing them with the string [scrubbed]. This way logs can

+    still be useful, but they don’t leave behind personally identifying

+    information about what sites a user might have visited.<br />

+<br />

+    If this option is set to 0, Tor will not perform any scrubbing, if it is

+    set to 1, all potentially sensitive strings are replaced. (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>User</strong> <em>UID</em>

+</dt>

+<dd>

+<p>

+    On startup, setuid to this user and setgid to their primary group.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HardwareAccel</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If non-zero, try to use built-in (static) crypto hardware acceleration when

+    available. This is untested and probably buggy. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>AvoidDiskWrites</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If non-zero, try to write to disk less frequently than we would otherwise.

+    This is useful when running on flash memory or other media that support

+    only a limited number of writes. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TunnelDirConns</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If non-zero, when a directory server we contact supports it, we will build

+    a one-hop circuit and make an encrypted connection via its ORPort.

+    (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>PreferTunneledDirConns</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If non-zero, we will avoid directory servers that don’t support tunneled

+    directory connections, when possible. (Default: 1)

+</p>

+</dd>

+</dl></div>

+</div>

+<h2 id="_client_options">CLIENT OPTIONS</h2>

+<div class="sectionbody">

+<div class="paragraph"><p>The following options are useful only for clients (that is, if

+<strong>SocksPort</strong> is non-zero):</p></div>

+<div class="dlist"><dl>

+<dt class="hdlist1">

+<strong>AllowInvalidNodes</strong> <strong>entry</strong>|<strong>exit</strong>|<strong>middle</strong>|<strong>introduction</strong>|<strong>rendezvous</strong>|<strong>&#8230;</strong>

+</dt>

+<dd>

+<p>

+    If some Tor servers are obviously not working right, the directory

+    authorities can manually mark them as invalid, meaning that it’s not

+    recommended you use them for entry or exit positions in your circuits. You

+    can opt to use them in some circuit positions, though. The default is

+    "middle,rendezvous", and other choices are not advised.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ExcludeSingleHopRelays</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    This option controls whether circuits built by Tor will include relays with

+    the AllowSingleHopExits flag set to true. If ExcludeSingleHopRelays is set

+    to 0, these relays will be included. Note that these relays might be at

+    higher risk of being seized or observed, so they are not normally

+    included. Also note that relatively few clients turn off this option,

+    so using these relays might make your client stand out.

+    (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>Bridge</strong> <em>IP</em>:<em>ORPort</em> [fingerprint]

+</dt>

+<dd>

+<p>

+    When set along with UseBridges, instructs Tor to use the relay at

+    "IP:ORPort" as a "bridge" relaying into the Tor network. If "fingerprint"

+    is provided (using the same format as for DirServer), we will verify that

+    the relay running at that location has the right fingerprint. We also use

+    fingerprint to look up the bridge descriptor at the bridge authority, if

+    it’s provided and if UpdateBridgesFromAuthority is set too.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>CircuitBuildTimeout</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    Try for at most NUM seconds when building circuits. If the circuit isn't

+    open in that time, give up on it. (Default: 1 minute.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>CircuitIdleTimeout</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    If we have kept a clean (never used) circuit around for NUM seconds, then

+    close it. This way when the Tor client is entirely idle, it can expire all

+    of its circuits, and then expire its TLS connections. Also, if we end up

+    making a circuit that is not useful for exiting any of the requests we’re

+    receiving, it won’t forever take up a slot in the circuit list. (Default: 1

+    hour.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ClientOnly</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If set to 1, Tor will under no circumstances run as a server or serve

+    directory requests. The default is to run as a client unless ORPort is

+    configured. (Usually, you don’t need to set this; Tor is pretty smart at

+    figuring out whether you are reliable and high-bandwidth enough to be a

+    useful server.) (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ExcludeNodes</strong> <em>node</em>,<em>node</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    A list of identity fingerprints, nicknames, country codes and address

+    patterns of nodes to never use when building a circuit. (Example:

+    ExcludeNodes SlowServer, $ EFFFFFFFFFFFFFFF, {cc}, 255.254.0.0/8)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ExcludeExitNodes</strong> <em>node</em>,<em>node</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    A list of identity fingerprints, nicknames, country codes and address

+    patterns of nodes to never use when picking an exit node. Note that any

+    node listed in ExcludeNodes is automatically considered to be part of this

+    list.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>EntryNodes</strong> <em>node</em>,<em>node</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    A list of identity fingerprints, nicknames and address

+    patterns of nodes to use for the first hop in normal circuits. These are

+    treated only as preferences unless StrictNodes (see below) is also set.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ExitNodes</strong> <em>node</em>,<em>node</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    A list of identity fingerprints, nicknames, country codes and address

+    patterns of nodes to use for the last hop in normal exit circuits. These

+    are treated only as preferences unless StrictNodes (see below) is also set.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>StrictEntryNodes</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor will never use any nodes besides those listed in "EntryNodes" for

+    the first hop of a circuit.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>StrictExitNodes</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor will never use any nodes besides those listed in "ExitNodes" for

+    the last hop of a circuit.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FascistFirewall</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor will only create outgoing connections to ORs running on ports

+    that your firewall allows (defaults to 80 and 443; see <strong>FirewallPorts</strong>).

+    This will allow you to run Tor as a client behind a firewall with

+    restrictive policies, but will not allow you to run as a server behind such

+    a firewall. If you prefer more fine-grained control, use

+    ReachableAddresses instead.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FirewallPorts</strong> <em>PORTS</em>

+</dt>

+<dd>

+<p>

+    A list of ports that your firewall allows you to connect to. Only used when

+    <strong>FascistFirewall</strong> is set. This option is deprecated; use ReachableAddresses

+    instead. (Default: 80, 443)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>HidServAuth</strong> <em>onion-address</em> <em>auth-cookie</em> [<em>service-name</em>]

+</dt>

+<dd>

+<p>

+    Client authorization for a hidden service. Valid onion addresses contain 16

+    characters in a-z2-7 plus ".onion", and valid auth cookies contain 22

+    characters in A-Za-z0-9+/. The service name is only used for internal

+    purposes, e.g., for Tor controllers. This option may be used multiple times

+    for different hidden services. If a hidden service uses authorization and

+    this option is not set, the hidden service is not accessible. Hidden

+    services can be configured to require authorization using the

+    <strong>HiddenServiceAuthorizeClient</strong> option.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ReachableAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]&#8230;

+</dt>

+<dd>

+<p>

+    A comma-separated list of IP addresses and ports that your firewall allows

+    you to connect to. The format is as for the addresses in ExitPolicy, except

+    that "accept" is understood unless "reject" is explicitly provided. For

+    example, 'ReachableAddresses 99.0.0.0/8, reject 18.0.0.0/8:80, accept

+    *:80' means that your firewall allows connections to everything inside net

+    99, rejects port 80 connections to net 18, and accepts connections to port

+    80 otherwise. (Default: 'accept *:*'.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ReachableDirAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]&#8230;

+</dt>

+<dd>

+<p>

+    Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey

+    these restrictions when fetching directory information, using standard HTTP

+    GET requests. If not set explicitly then the value of

+    <strong>ReachableAddresses</strong> is used. If <strong>HTTPProxy</strong> is set then these

+    connections will go through that proxy.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>ReachableORAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]&#8230;

+</dt>

+<dd>

+<p>

+    Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey

+    these restrictions when connecting to Onion Routers, using TLS/SSL. If not

+    set explicitly then the value of <strong>ReachableAddresses</strong> is used. If

+    <strong>HTTPSProxy</strong> is set then these connections will go through that proxy.<br />

+<br />

+    The separation between <strong>ReachableORAddresses</strong> and

+    <strong>ReachableDirAddresses</strong> is only interesting when you are connecting

+    through proxies (see <strong>HTTPProxy</strong> and <strong>HTTPSProxy</strong>). Most proxies limit

+    TLS connections (which Tor uses to connect to Onion Routers) to port 443,

+    and some limit HTTP GET requests (which Tor uses for fetching directory

+    information) to port 80.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>LongLivedPorts</strong> <em>PORTS</em>

+</dt>

+<dd>

+<p>

+    A list of ports for services that tend to have long-running connections

+    (e.g. chat and interactive shells). Circuits for streams that use these

+    ports will contain only high-uptime nodes, to reduce the chance that a node

+    will go down before the stream is finished. (Default: 21, 22, 706, 1863,

+    5050, 5190, 5222, 5223, 6667, 6697, 8300)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>MapAddress</strong> <em>address</em> <em>newaddress</em>

+</dt>

+<dd>

+<p>

+    When a request for address arrives to Tor, it will rewrite it to newaddress

+    before processing it. For example, if you always want connections to

+    www.indymedia.org to exit via <em>torserver</em> (where <em>torserver</em> is the

+    nickname of the server), use "MapAddress www.indymedia.org

+    www.indymedia.org.torserver.exit".

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>NewCircuitPeriod</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    Every NUM seconds consider whether to build a new circuit. (Default: 30

+    seconds)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>MaxCircuitDirtiness</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    Feel free to reuse a circuit that was first used at most NUM seconds ago,

+    but never attach a new stream to a circuit that is too old. (Default: 10

+    minutes)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>NodeFamily</strong> <em>node</em>,<em>node</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    The Tor servers, defined by their identity fingerprints or nicknames,

+    constitute a "family" of similar or co-administered servers, so never use

+    any two of them in the same circuit. Defining a NodeFamily is only needed

+    when a server doesn’t list the family itself (with MyFamily). This option

+    can be used multiple times.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>EnforceDistinctSubnets</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If 1, Tor will not put two servers whose IP addresses are "too close" on

+    the same circuit. Currently, two addresses are "too close" if they lie in

+    the same /16 range. (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SocksPort</strong> <em>PORT</em>

+</dt>

+<dd>

+<p>

+    Advertise this port to listen for connections from Socks-speaking

+    applications. Set this to 0 if you don’t want to allow application

+    connections. (Default: 9050)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SocksListenAddress</strong> <em>IP</em>[:<em>PORT</em>]

+</dt>

+<dd>

+<p>

+    Bind to this address to listen for connections from Socks-speaking

+    applications. (Default: 127.0.0.1) You can also specify a port (e.g.

+    192.168.0.1:9100). This directive can be specified multiple times to bind

+    to multiple addresses/ports.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SocksPolicy</strong> <em>policy</em>,<em>policy</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    Set an entrance policy for this server, to limit who can connect to the

+    SocksPort and DNSPort ports. The policies have the same form as exit

+    policies below.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SocksTimeout</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    Let a socks connection wait NUM seconds handshaking, and NUM seconds

+    unattached waiting for an appropriate circuit, before we fail it. (Default:

+    2 minutes.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TrackHostExits</strong> <em>host</em>,<em>.domain</em>,<em>&#8230;</em>

+</dt>

+<dd>

+<p>

+    For each value in the comma separated list, Tor will track recent

+    connections to hosts that match this value and attempt to reuse the same

+    exit node for each. If the value is prepended with a '.', it is treated as

+    matching an entire domain. If one of the values is just a '.', it means

+    match everything. This option is useful if you frequently connect to sites

+    that will expire all your authentication cookies (i.e. log you out) if

+    your IP address changes. Note that this option does have the disadvantage

+    of making it more clear that a given history is associated with a single

+    user. However, most people who would wish to observe this will observe it

+    through cookies or other protocol-specific means anyhow.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TrackHostExitsExpire</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    Since exit servers go up and down, it is desirable to expire the

+    association between host and exit server after NUM seconds. The default is

+    1800 seconds (30 minutes).

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>UpdateBridgesFromAuthority</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When set (along with UseBridges), Tor will try to fetch bridge descriptors

+    from the configured bridge authorities when feasible. It will fall back to

+    a direct request if the authority responds with a 404. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>UseBridges</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When set, Tor will fetch descriptors for each bridge listed in the "Bridge"

+    config lines, and use these relays as both entry guards and directory

+    guards. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>UseEntryGuards</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    If this option is set to 1, we pick a few long-term entry servers, and try

+    to stick with them. This is desirable because constantly changing servers

+    increases the odds that an adversary who owns some servers will observe a

+    fraction of your paths. (Defaults to 1.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>NumEntryGuards</strong> <em>NUM</em>

+</dt>

+<dd>

+<p>

+    If UseEntryGuards is set to 1, we will try to pick a total of NUM routers

+    as long-term entries for our circuits. (Defaults to 3.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>SafeSocks</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When this option is enabled, Tor will reject application connections that

+    use unsafe variants of the socks protocol — ones that only provide an IP

+    address, meaning the application is doing a DNS resolve first.

+    Specifically, these are socks4 and socks5 when not doing remote DNS.

+    (Defaults to 0.)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TestSocks</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When this option is enabled, Tor will make a notice-level log entry for

+    each connection to the Socks port indicating whether the request used a

+    safe socks protocol or an unsafe one (see above entry on SafeSocks). This

+    helps to determine whether an application using Tor is possibly leaking

+    DNS requests. (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>VirtualAddrNetwork</strong> <em>Address</em>/<em>bits</em>

+</dt>

+<dd>

+<p>

+    When Tor needs to assign a virtual (unused) address because of a MAPADDRESS

+    command from the controller or the AutomapHostsOnResolve feature, Tor

+    picks an unassigned address from this range. (Default:

+    127.192.0.0/10)<br />

+<br />

+    When providing proxy server service to a network of computers using a tool

+    like dns-proxy-tor, change this address to "10.192.0.0/10" or

+    "172.16.0.0/12". The default <strong>VirtualAddrNetwork</strong> address range on a

+    properly configured machine will route to the loopback interface. For

+    local use, no change to the default VirtualAddrNetwork setting is needed.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>AllowNonRFC953Hostnames</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When this option is disabled, Tor blocks hostnames containing illegal

+    characters (like @ and :) rather than sending them to an exit node to be

+    resolved. This helps trap accidental attempts to resolve URLs and so on.

+    (Default: 0)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>FastFirstHopPK</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When this option is disabled, Tor uses the public key step for the first

+    hop of creating circuits. Skipping it is generally safe since we have

+    already used TLS to authenticate the relay and to establish forward-secure

+    keys. Turning this option off makes circuit building slower.<br />

+<br />

+    Note that Tor will always use the public key step for the first hop if it’s

+    operating as a relay, and it will never use the public key step if it

+    doesn’t yet know the onion key of the first hop. (Default: 1)

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TransPort</strong> <em>PORT</em>

+</dt>

+<dd>

+<p>

+    If non-zero, enables transparent proxy support on <em>PORT</em> (by convention,

+    9040). Requires OS support for transparent proxies, such as BSDs' pf or

+    Linux’s IPTables. If you’re planning to use Tor as a transparent proxy for

+    a network, you’ll want to examine and change VirtualAddrNetwork from the

+    default setting. You’ll also want to set the TransListenAddress option for

+    the network you’d like to proxy. (Default: 0).

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>TransListenAddress</strong> <em>IP</em>[:<em>PORT</em>]

+</dt>

+<dd>

+<p>

+    Bind to this address to listen for transparent proxy connections. (Default:

+    127.0.0.1). This is useful for exporting a transparent proxy server to an

+    entire network.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>NATDPort</strong> <em>PORT</em>

+</dt>

+<dd>

+<p>

+    Allow old versions of ipfw (as included in old versions of FreeBSD, etc.)

+    to send connections through Tor using the NATD protocol. This option is

+    only for people who cannot use TransPort.

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>NATDListenAddress</strong> <em>IP</em>[:<em>PORT</em>]

+</dt>

+<dd>

+<p>

+    Bind to this address to listen for NATD connections. (Default: 127.0.0.1).

+</p>

+</dd>

+<dt class="hdlist1">

+<strong>AutomapHostsOnResolve</strong> <strong>0</strong>|<strong>1</strong>

+</dt>

+<dd>

+<p>

+    When this option is enabled, and we get a request to resolve an address

+    that ends with one of the suffixes in <strong>AutomapHostsSuffixes</strong>, we map an

+    unused virtual address to that address, and return the new virtual address.

+    This is handy for making ".onion" addresses work with applications that

+    resolve an address and then connect to it. (Default: 0).

+</p>