Relay Operators

  • 不要使用 Ubuntu 仓库中的包,它们未得到可靠更新。 如果您使用它们,您可能会错过重要的稳定性和安全性修复。
  • 运行下面的命令确定你 Ubuntu 的版本
     ‪$ lsb_release -c
    
  • 以 root 用户身份把下面的行添加到 /etc/apt/sources.list 中。用前一步你获得的版本号代替'version'。
     deb https://deb.torproject.org/torproject.org version main
     deb-src https://deb.torproject.org/torproject.org version main
    
  • 运行下面的命令来添加签名软件包的 gpg 公钥:
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
    
  • 运行下面的命令来检查签名并安装 tor:
     ‪$ sudo apt-get update
     ‪$ sudo apt-get install tor deb.torproject.org-keyring
    

简而言之,它这样工作:

  • There is a primary ed25519 identity secret key file named "ed25519_master_id_secret_key". 这是最重要的一个,所以请确保您在安全的地方存有备份——这份文件十分敏感,应得到充分保护。 如果您手动生成它,Tor 会对它进行加密并在被要求时输入密码。
  • 一个叫"ed25519_signing_secret_key"的中期签名密钥已经被生成,供Tor 使用。 Also, a certificate is generated named "ed25519_signing_cert" which is signed by the primary identity secret key and confirms that the medium term signing key is valid for a certain period of time. 默认有效期为30天,但这个时长可以在torrc里通过设置" 签名密钥有效时间 N 天|周|月 "来自行调节。
  • There is also a primary public key named "ed25519_master_id_public_key", which is the actual identity of the relay advertised in the network. This one is not sensitive and can be easily computed from "ed5519_master_id_secret_key".

Tor will only need access to the medium term signing key and certificate as long as they are valid, so the primary identity secret key can be kept outside DataDirectory/keys, on a storage media or a different computer. 您不得不在中期签名密钥和认证过期前手动更新它们,否则中继服务器上的Tor 进程会在到期时立刻退出。

这个功能是可选的,您不需要使用它除非您想这么做。 If you want your relay to run unattended for longer time without having to manually do the medium term signing key renewal on regular basis, best to leave the primary identity secret key in DataDirectory/keys, just make a backup in case you'll need to reinstall it. 如果您想要使用这个特殊功能,请参考我们在这个话题上更详细的指南

Tor has partial support for IPv6 and we encourage every relay operator to enable IPv6 functionality in their torrc configuration files when IPv6 connectivity is available. Tor 目前需要中继的 IPv4 地址,您不能在仅有 IPv6 的主机上运行 Tor 中继。

您是正确的,在大多数情况下,您的 Tor 中继服务器进一个比特就意味着要出一个比特,反之亦然。但也有几个例外:

如果您打开了您的 DirPort,那么 Tor 的客户端就会向您索要一份目录的拷贝。 他们发出的请求(一个 HTTP GET)十分的小,然而回复有时会非常大。 这应该能解释大多数您的“写入”比特量与“读取”比特量之间的不符。

当您以出口节点运行,并阅读了来自出口连接的几比特信息(比如一则即时信息或ssh连接),把它包裹成一个完整的512比特包以便在 Tor 网络里运输时,一个小小的例外会出现。

我们旨在让搭建一个Tor 中继简单而又边界:

  • 如果中继有时下线,这并没有关系。 目录系统会迅速注意到这一点,并停止发布该中继。 但请试图确保这并不会太频繁地发生,因为当中继断连时,正在使用该中继进行的连接也会断开。
  • 每个 Tor 中继服务器都有一个出口法规则,它详细规定了中继服务器应该同意什么样的外部连接,或是拒绝什么样的外部连接。 如果你不喜欢允许别人的流量经由你的中继出口,你可以设置成仅允许从其他 Tor 中继的连接。
  • 您的中继服务器会被动地估计并公布它最近的带宽容量,所以高带宽的中继服务器会比低带宽服务器吸引更多的用户。因此,拥有低带宽中继服务器也是有用的。

Tor 进程的两个客户和中继服务器功能都适用于在 AccountingMax带宽率里分配的参数。 因此您可能会发现,一旦您的 Tor 进入休眠,您就不能进行浏览了,而且在日志里会出现这样一条记录:

Bandwidth soft limit reached; commencing hibernation.
新的连接将被拒绝。

解决方案是运行两个Tor 进程——一个中继和一个客户端,每一个进程使用自己的配置。 做到这一点(如果您是从一个正在工作的中继服务器设置开始的话)的一种方法如下:

  • 在中继的Tor torrc文件中,将SocksPort设置为0.
  • 从torrc.样例中创建一个新的用户torrc 文件,并确保它与中继服务器使用的不是同一个登陆文件。 一种命名约定可以是 torrc.client 和 torrc.relay。
  • 修改 Tor 客户端和中继服务器启动脚本来包括-f /path/to/correct/torrc
  • 在 Linux/BSD/Mac OS X 系统中,将启动脚本改为Tor.clientTor.relay可以使系统配置的分离变得更轻松。

We're looking for people with reasonably reliable Internet connections, that have at least 10 Mbit/s (Mbps) available bandwidth each way. If that's you, please consider running a Tor relay.

Even if you do not have at least 10 Mbit/s of available bandwidth you can still help the Tor network by running a Tor bridge with obfs4 support. In that case you should have at least 1 MBit/s of available bandwidth.

关于如何用您的 NAT/路由设备进行端口转发的指导,参见 portforward.com

如果您的中继在内网运行,您需要设置端口转发。 Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

另外,这还有一个说明如何在 GNU/Linux 下使用 iptables 操作的例子。

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 9001 -j ACCEPT

如果您有不同的(连接到互联网的)外部接口,您可能需要改动"eth0"。 因为您可能只有一个(除了环回接口)所以这应该不难找。

BridgeDB implements four mechanisms to distribute bridges: HTTPS, Moat, Email, and Reserved. Bridge operators can check which mechanism their bridge is using, on the Relay Search. Enter the bridge's <HASHED FINGERPRINT> in the form and click "Search".

Operators can also choose which distribution method their bridge uses. To change the method, modify the BridgeDistribution setting in the torrc file to one of these: https, moat, email, none, any.

Read more on the Bridges post-install guide.

是的,您在一些攻击中确实能获得更好的匿名性。

最简单的例子是一个拥有一些数量Tor 中继的攻击者。 他们会看见一个来自您的连接,但他们不会知道这个连接是来自于您的电脑还是您的中继上的其他人。

有些情况下,它不能帮助我们:如果一个网络入侵者观看了你所有的来来往往的通信,那么他很容易发现哪些连接被转接了,哪些连接从你开始。 (在这个情况下,他们仍然不知道您的目的地址,除非他们也在观察它们,但您也没有比一个普通客户好到哪里。)

运行一个Tor中继也有一些坏处。 首先,我们只有几百个中继服务器,而您恰好在运行其中一个。这个事实对于攻击者来说就是一个信号,告诉他们您把匿名看的很重要。 第二,有一些更深奥的、没有被很好理解或测试的攻击利用了您正在运行中继服务器这一点——比如,一个攻击者即使不能真的看见您的网络,他也能通过使用您的Tor中继服务器发送消息并留意通信时间,从而“观察”到您是否在发送信息

收益是否大于风险是一个开放的研究性问题。 很大程度上这取决于您最担心的攻击方式。 对于大多数用户来说,我们认为这是一种明智的举动。

既然它现在是一名守卫了,客户们在其他地方使用它的频率变低了,但还没有许多客户将他们已有的守卫移走并把它当作守卫使用。 在这篇博客帖子 里查阅更多详情,或查看守卫的变迁:理解和优化Tor的入口守卫选项的框架

如果您允许了出口节点连接,那么人们通过您的中继服务器连接的一些服务就会连接回来,以收集更多关于您的信息。比如,一些 IRC 服务器会连接回您的identd接口来记录哪些用户建立了连接。(这实际上并不会奏效,因为 Tor 不知道这些信息,但他们还是会试一试。)此外,从您的节点出去的用户也许会吸引其他在 RC 服务器、网站等上的用户的注意,这些用户可能想要了解更多关于他们正在使用的这个中继服务器的主人的信息。

另一个原因是,在互联网上扫描公共代理的小组意识到有时 Tor 中继服务器会将它们的socks接口暴露给全世界。我们推荐您将socks接口只与本地网络捆绑。

在任何情况下,您都需要保持您的安全措施是最新的。在 Tor 中继服务器的安全措施 上阅读这篇文章以获得更多建议。

On relay search we show an amber dot next to the relay nickname when this is overloaded. This means that one or many of the following load metrics have been triggered:

Note that if a relay reaches an overloaded state we show it for 72 hours after the relay has recovered.

If you notice that your relay is overloaded please:

  1. Check https://status.torproject.org/ for any known issues in the "Tor network" category.

  2. Consider tuning sysctl for your system for network, memory and CPU load.

  3. Consider enabling MetricsPort to understand what is happening.

Tuning sysctl for network, memory and CPU load

TCP port exhaustion

If you are experiencing TCP port exhaustion consider expanding your local port range. You can do that with

# sysctl -w net.ipv4.ip_local_port_range="15000 64000"

# echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range

DNS timeout

If you are experiencing DNS timeout, you should investigate if this is a network or a resolver issue.

In Linux in resolve.conf there is an option to set a timeout:

timeout:n
  Sets  the  amount of time the resolver will wait for a response from a remote
  name server before retrying the query via a different name server.
  This may not be the total time taken by any resolver API call and there is no guarantee
  that a single resolver API call maps to a single timeout.
  Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>).
  The value for this option is silently capped to 30.

Check $ man resolve.conf for more information.

MetricsPort

Consider enabling MetricsPort to understand what is happening.

MetricsPort data for relays has been introduced since version >= 0.4.7.1-alpha, while the overload data has been added to the relay descriptors since 0.4.6+.

It's important to understand that exposing the tor MetricsPort publicly is dangerous for the Tor network users.

Please take extra precaution and care when opening this port, and close it when you are done debugging. Set a very strict access policy with MetricsPortPolicy and consider using your operating systems firewall features for defense in depth.

Here is an example of what output enabling MetricsPort will produce:

‪# HELP tor_relay_load_onionskins_total Total number of onionskins handled
‪# TYPE tor_relay_load_onionskins_total counter
tor_relay_load_onionskins_total{type="tap",action="processed"} 0
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 0
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0
‪# HELP tor_relay_exit_dns_query_total Total number of DNS queries done by this relay
‪# TYPE tor_relay_exit_dns_query_total counter
tor_relay_exit_dns_query_total{record="A"} 0
tor_relay_exit_dns_query_total{record="PTR"} 0
tor_relay_exit_dns_query_total{record="AAAA"} 0
‪# HELP tor_relay_exit_dns_error_total Total number of DNS errors encountered by this relay
‪# TYPE tor_relay_exit_dns_error_total counter
tor_relay_exit_dns_error_total{record="A",reason="success"} 0
tor_relay_exit_dns_error_total{record="A",reason="format"} 0
tor_relay_exit_dns_error_total{record="A",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="A",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="A",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="A",reason="refused"} 0
tor_relay_exit_dns_error_total{record="A",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="A",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="A",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="A",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="A",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="A",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="success"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="format"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="refused"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="success"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="format"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="refused"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="nodata"} 0
‪# HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran out of TCP ports
‪# TYPE tor_relay_load_tcp_exhaustion_total counter
tor_relay_load_tcp_exhaustion_total 0
‪# HELP tor_relay_load_socket_total Total number of sockets
‪# TYPE tor_relay_load_socket_total gauge
tor_relay_load_socket_total{state="opened"} 135
tor_relay_load_socket_total 1048544
‪# HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has freed by subsystem
‪# TYPE tor_relay_load_oom_bytes_total counter
tor_relay_load_oom_bytes_total{subsys="cell"} 0
tor_relay_load_oom_bytes_total{subsys="dns"} 0
tor_relay_load_oom_bytes_total{subsys="geoip"} 0
tor_relay_load_oom_bytes_total{subsys="hsdir"} 0
‪# HELP tor_relay_load_global_rate_limit_reached_total Total number of global connection bucket limit reached
‪# TYPE tor_relay_load_global_rate_limit_reached_total counter
tor_relay_load_global_rate_limit_reached_total{side="read"} 0
tor_relay_load_global_rate_limit_reached_total{side="write"} 0

Let's find out what some of these lines actually mean:

tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0

When a relay starts seeing "dropped", it is a CPU/RAM problem usually.

Tor is sadly single threaded except for when the "onion skins" are processed. The "onion skins" are the cryptographic work that needs to be done on the famous "onion layers" in every circuits.

When tor processes the layers we use a thread pool and outsource all of that work to that pool. It can happen that this pool starts dropping work due to memory or CPU pressure and this will trigger an overload state.

If your server is running at capacity this will likely be triggered.

‪tor_relay_exit_dns_error_total{...}

Any counter in the "*_dns_error_total" realm indicates a DNS problem.

DNS timeouts issues only apply to Exit nodes. If tor starts noticing DNS timeouts, you'll get the overload flag. This might not be because your relay is overloaded in terms of resources but it signals a problem on the network.

DNS timeouts at the Exits are a huge UX problem for tor users. Therefore Exit operators really need to address these issues to help the network.

‪tor_relay_load_oom_bytes_total{...}

An Out-Of-Memory invocation indicates a RAM problem. The relay might need more RAM or it is leaking memory. If you noticed that the tor process is leaking memory, please report the issue either via Tor gitLab or sending an email to the tor-relays mailing list.

Tor has its own OOM handler and it is invoked when 75%, of the total memory tor thinks is available, is reached. Thus, let say tor thinks it can use 2GB in total then at 1.5GB of memory usage, it will start freeing memory. That is considered an overload state.

To estimate the amount of memory it has available, when tor starts, it will use MaxMemInQueues or, if not set, will look at the total RAM available on the system and apply this algorithm:

    if RAM >= 8GB {
      memory = RAM * 40%
    } else {
      memory = RAM * 75%
    }
    /* Capped. */
    memory = min(memory, 8GB) -> [8GB on 64bit and 2GB on 32bit)
    /* Minimum value. */
    memory = max(250MB, memory)

To avoid an overloaded state we recommend to run a relay above 2GB of RAM on 64bit. 4GB is advised, although of course it doesn't hurt to add more RAM if you can.

One might notice that tor could be called by the OS OOM handler itself. Because tor takes the total memory on the system when it starts, if the overall system has many other applications running using RAM, it ends up eating too much memory. In this case the OS could OOM tor, without tor even noticing memory pressure.

tor_relay_load_socket_total

These lines indicate the relay is running out of sockets. The solution is to increase ulimit -n for the tor process.

tor_relay_load_tcp_exhaustion_total

These lines indicate the relay is running out of TCP ports.

Try to tune sysctl as described above.

tor_relay_load_global_rate_limit_reached_total

If this counter is incremented by some noticeable value over a short period of time, the relay is congested. It is likely being used as a Guard by a big onion service or for an ongoing DDoS on the network.

If your relay is still overloaded and you don't know why, please get in touch with network-report@torproject.org. You can encrypt your email using network-report OpenPGP key.

torrc文件里的会计选项让您能够明确规定您的中继服务器在一段时间内使用的最大流量。

    AccountingStart day week month [day] HH:MM

这详细规定了计数器应该在何时被重置。比方说,要想设置可供服务一星期的比特量(这在每周三上午10:00点会重置),您会使用:

    AccountingStart week 3 10:00
    AccountingMax 500 GBytes

这详细规定了您的中继服务器在一个计数周期内发送的最大数据量和接收的最大数据量。 当会计期间被(AcountingStart)重置后,AccountingMax 的计数器会被重置为0。

比如:假设您想要每天每个方向设置50GB的流量,那么计数器就应该在每天中午重置。

    AccountingStart day 12:00
    AccountingMax 50 GBytes

请注意,您的中继服务器不会在每个会计期间的一开始恰好被唤醒。 它会跟踪记录它在上一个时期里使用额度的速度有多快,并在新的时间间隔里选择一个随机的点唤醒。 这样我们就能避免数百个中继服务器在每个月的一开始就同时运行,结果在月末就没有服务器运行的情况发生。

相较于您的连接速率,如果您只能贡献一小部分带宽,我们推荐您使用日常账户,这样您就不会在每个月的第一天就把一整个月的额度全用光。 只要将您每月的限额除以30即可。您也可以考虑将流量限速,把您的额度覆盖更多的时间:如果您想要在每个方向提供X GB, 您可以将中继服务器的带宽率设为20*X KB. 比如,如果您每种方法都有50GB可提供,您也许要将您的中继服务器带宽率调为1000 KBytes: 这样您的中继服务器就总是可保持每天起码有一半的时间可以使用。

    AccountingStart day 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # 允许更高的短时流量但是保持平均

很棒! 这就是我们实施出口政策的原因。

每个 Tor 中继拥有一条出口规则,用于指定允许或拒绝何种类型的出站连接通过该中继。 出口政策通过目录传送给 Tor 的客户,所以客户会自动避免挑选会拒绝退出到他们想要到达的目的地的出口中继服务器。 这样一来,每个中继服务器都可以决定服务,主人和它想让连接到达的网络,这些都基于滥用的可能性和它自身的状况。 Read the Support entry on issues you might encounter if you use the default exit policy, and then read Mike Perry's tips for running an exit node with minimal harassment.

默认的出口中继协议允许许多流行服务的获取权(如网页浏览),但出于滥用的潜在风险,限制了一些服务(如邮箱),还有一些是因为流量大小超出了 Tor 网络的承受范围(如默认文件共享端口)。 您可以通过编辑您的torrc文件来更改您自己的出口策略。 If you want to avoid most if not all abuse potential, set it to "reject *:*". 这个设置意味着您的中继服务器只会被用来中继 Tor 网络内部的通讯,而不是外部的网站连接或其他服务。

如果您确实允许任何出口连接,确保域名解析正常(也就是,您的电脑能正确解析网络地址)。 如果有任何您的计算机不能访问的资源(比如您被限制性防火墙或内容过滤器拦住了),请明确的在您的出口节点规定里驳回它们,否则其他 Tor 的用户也会被影响。

如果您的中继才刚刚开始运行,请给它一些时间。 Tor 根据带宽权威机构的报告来决定使用哪个中继服务器。这些机构测量您的中继服务器的容量,并随着时间推移,引导更多的通讯流量至您的中继服务器,直到它达到最佳运载量。 一个新的中继服务器的生命周期在这个博客帖子 里解释的更为详尽。 如果您运行中继服务器已经有一段时间了,并仍然有疑问,那么请尝试在tor-中继服务器名单 上提问。

棒!如果您想允许几个中继来为网络贡献更多,我们很欢迎这样做。 但请不要在同一个网络上运行太多中继,因为分散与多样性是Tor 网络目标的一部分。

如果您真的决定要运行多个中继服务器,请打开每个中继服务器torrc上的“我的家庭”配置选项,列出在您控制下的所有中继服务器(用逗号隔开):

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

每个指纹是40个字母组成的身份指纹(没有空格)。

这样的话,Tor 客户就会记住不要在单个环路里使用超过一个您的中继服务器。 如果您有这些计算机或其网络管理上的控制权,您就应该设置我的家庭,即使它们不全在同一个地理位置。

The default open ports are listed below but keep in mind that, any port or ports can be opened by the relay operator by configuring it in torrc or modifying the source code. The default according to src/or/policies.c (line 85 and line 1901) from the source code release release-0.4.6:

reject 0.0.0.0/8
reject 169.254.0.0/16
reject 127.0.0.0/8
reject 192.168.0.0/16
reject 10.0.0.0/8
reject 172.16.0.0/12

reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:563
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*

Tor 通过询问计算机的主机名来猜测它的IP地址,然后解析那个主机名。人们往往在他们的 /etc/hosts 文件里有指向旧 IP 地址的旧条目。

如果那不能解决这个问题,您应该使用“地址”配置选项来具体说明您想选取的 IP 地址。如果您的计算机处于一个网络地址转换里,并只有一个内部IP地址,请查看以下关于如何进入动态IP地址的技术支持。

并且,如果您有许多地址,您可能也想要设置“OutboundBindAddress”,这样外部的连接就会来自您想要展示给世界的那个。

Why Relay Load Varies

Tor manages bandwidth across the entire network. It does a reasonable job for most relays. But Tor's goals are different to protocols like BitTorrent. Tor wants low-latency web pages, which requires fast connections with headroom. BitTorrent wants bulk downloads, which requires using all the bandwidth.

We're working on a new bandwidth scanner, which is easier to understand and maintain. It will have diagnostics for relays that don't get measured, and relays that have low measurements.

Why does Tor need bandwidth scanners?

Most providers tell you the maximum speed of your local connection. But Tor has users all over the world, and our users connect to one or two Guard relays at random. So we need to know how well each relay can connect to the entire world.

So even if all relay operators set their advertised bandwidth to their local connection speed, we would still need bandwidth authorities to balance the load between different parts of the Internet.

What is a normal relay load?

It's normal for most relays to be loaded at 30%-80% of their capacity. This is good for clients: an overloaded relay has high latency. (We want enough relays to so that each relay is loaded at 10%. Then Tor would be almost as fast as the wider Internet).

Sometimes, a relay is slow because its processor is slow or its connections are limited. Other times, it is the network that is slow: the relay has bad peering to most other tor relays, or is a long distance away.

Finding Out what is Limiting a Relay

Lots of things can slow down a relay. Here's how to track them down.

System Limits

  • Check RAM, CPU, and socket/file descriptor usage on your relay

Tor logs some of these when it starts. Others can be viewed using top or similar tools.

Provider Limits

  • Check the Internet peering (bandwidth, latency) from your relay's provider to other relays. Relays transiting via Comcast have been slow at times. Relays outside North America and Western Europe are usually slower.

Tor Network Limits

Relay bandwidth can be limited by a relay's own observed bandwidth, or by the directory authorities' measured bandwidth. Here's how to find out which measurement is limiting your relay:

  • Check each of the votes for your relay on consensus-health (large page), and check the median. If your relay is not marked Running by some directory authorities:
    • Does it have the wrong IPv4 or IPv6 address?
    • Is its IPv4 or IPv6 address unreachable from some networks?
    • Are there more than 2 relays on its IPv4 address?

Otherwise, check your relay's observed bandwidth and bandwidth rate (limit). Look up your relay on Metrics. Then mouse over the bandwidth heading to see the observed bandwidth and relay bandwidth rate.

Here is some more detail and some examples: Drop in consensus weight and Rampup speed of Exit relay.

How to fix it

The smallest of these figures is limiting the bandwidth allocated to the relay.

  • If it's the bandwidth rate, increase the BandwidthRate/Burst or RelayBandwidthRate/Burst in your torrc.
  • If it's the observed bandwidth, your relay won't ask for more bandwidth until it sees itself getting faster. You need to work out why it is slow.
  • If it's the median measured bandwidth, your relay looks slow from a majority of bandwidth authorities. You need to work out why they measure it slow.

Doing Your Own Relay Measurements

If your relay thinks it is slow, or the bandwidth authorities think it is slow, you can test the bandwidth yourself:

  • Run a test using tor to see how fast tor can get on your network/CPU.
  • Run a test using tor and chutney to find out how fast tor can get on your CPU. Keep increasing the data volume until the bandwidth stops increasing.

  • 出口节点是需求最大的一种中继服务器,但同时,它也面临着最大程度上的法律曝光和风险(而且您不应该在您的家里运行它们
  • 如果您正想要运行一个最简单的中继,快速守卫中继也十分有用。
  • Followed by bridges.

您有两种添加至 torrc 的方法:

带宽率是指条件允许的情况下,最大的长时间传输带宽(字节每秒)。 比如,您也许想要选择“10M带宽率”来获得10兆字节每秒的传输速率(十分快速的连接),或者“500KB带宽率”来获取0.5兆每秒的传输速率(相当于一个不错的有线电缆传输速率)。 最小的 BandwidthRate 是 75KB 每秒。

BandwidthBurst是一个字节池,用于满足短期流量高于 BandwidthRate 但长期平均流量低于 BandwidthRate 的需求。 A low Rate but a high Burst enforces a long-term average while still allowing more traffic during peak times if the average hasn't been reached lately. 比如,如果您选择了“带宽突发传输率 500KBytes” 并应用到您的带宽率,那么您的网速就永运不会超过50万字节每秒;但如果您选择了一个更高的带宽突发传输率(如5 MBytes),它就会允许更多的数据通过,直到资源池已满。

如果您有不对称的连接(上传小于下载),比如一个电缆调制解调器,您应该把带宽率设置成小于您更小的那个带宽(通常就是上传带宽)。 否则,你可能会在最大带宽使用时掉包——你可能需要试验一下哪些值使你的连接顺畅。 然后设置BandwidthBurst与BandwidthRate相同。

基于 Linux 系统的 Tor 节点提供了另外一种选择:他们会优先将Tor置于其他运行网络之下,因此他们的私人网络运作不会被 Tor 影响。 A script to do this can be found in the Tor source distribution's contrib directory.

此外,您可以使用冬眠选项来告诉tor在每个特定时间段里只服务一定的带宽(比如每月100GB)。这些选项在下方的冬眠入口里。

请注意,带宽率和带宽突发传输率都是以字节而不是比特为单位的。

不要这么做。 如果司法部门察觉了你出口节点的数据流量,他们可能会没收你的电子设备。 出于这些原因,最好不要在你的家中或使用你家里的网络运行出口节点。

推荐在支持 Tor 的商业实体(例如某些 VPS 服务商 —— 译者注)上搭建 Tor 的出口节点。 你的出口节点有一个独立的 IP 地址,而且不会传输你的流量。 当然,你应该避免在你运行出口节点的电脑上存储任何敏感或与你有关的信息。

所有的传出连接必须被允许,这样每一个中继才可以与其他中继互相通讯。

在许多司法管辖区,Tor 中继服务器运行者是受公共承运人法律保护的,这条法律保护互联网服务提供者免受潜在的传播第三方内容的法律风险。 过滤某些流量的出口节点将丧失那些保护。

Tor促进了免费无干扰的网络访问。 出口中继不得过滤通过中继的互联网流量。 被检测到过滤流量的出口节点会被打上劣质出口的标签。

当一个出口被错误地配置了,或是一个恶意出口,它会被分配给损坏出口标志。这会让 Tor 避免将那个中继服务器作为出口。事实上,有着这个标志的中继服务器就相当于不存在。 如果您有了这个旗帜标志,那么说明我们在从您的出口节点路由通信时发现了问题或可疑活动,但无法联系上您。请与问题中继服务器团队 取得联系,这样我们才能整治问题。

想了解更深入了解如何运行一个中继服务器,请参阅中继服务器设置指南

Tor可以很好地处理使用动态IP地址的中继,这没有关系。 您只需要将您的torrc文件中的”Address“留空,然后 Tor 会猜出它来。

在升级您的 Tor 中继服务器,或把它转移到另一台计算机上时,重要的是保持同样的身份密钥(存储于您的数据词典里的"keys/ed25519_master_id_secret_key" and "keys/secret_id_key")。 给身份密钥进行备份,这样您就可以在未来修复中继服务器。这是我们推荐的确保中继服务器的名誉不被浪费的方法。

这意味着,如果您正在升级您的 Tor 中继服务器,且您没有更改torrc和数据词典,那么升级过程不会出现问题,您的中继服务器会继续使用相同的密钥。 如果您需要选择一个新的数据词典,请确保复制了您旧的keys/ed25519_master_id_secret_key and keys/secret_id_key。

Note: As of Tor 0.2.7 we are using new generation identities for relays based on ed25519 elliptic curve cryptography. 最终它们会取代老的 RSA 身份,来确保老版本的兼容性,但这不会立即发生。 直到那时,每个中继服务器都会有一个ed25519身份(身份密钥文件:keys/ed25519_master_id_secret_key)和一个 RSA 身份(身份密钥文件:keys/secret_id_key)。 您需要将两者都拷贝 / 备份,以便恢复您的中继服务器,更改您的数据词典或将中继服务器移植到另一台计算机上。

如果您的 Tor 中继服务器使用了比您预想中更多的记忆储存,这儿有几条减少足迹的贴士:

  • 如果您是 Linux 操作系统,您也许会在glibc的动态内存分配操作里遇到记忆储存碎片故障。 这就是说,当 or 将记忆储存释放回系统后,这些记忆储存的片段被分成了许多碎片,很难再被利用。 Tor 原始码是用 OpenBSD 的动态内存分配操作进行运输的,这个方法没有那么多的碎片故障(但代价是更高的 CPU 负荷)。 You can tell Tor to use this malloc implementation instead: ./configure --enable-openbsd-malloc.
  • 如果您正在运行一个高速中继服务器,这意味着您拥有许多 TLS 连接处于打开状态,您可能正有大量记忆储存流失到了 OpenSSL 的内部缓冲储存器里。(每个数据包 38KB+) 我们已经给 OpenSSL 打过了补丁,来更激进地释放未使用的缓冲区记忆储存. 如果您升级到 OpenSSL 1.0.0或更新的版本,Tor 的构造进程会自动识别并使用这个特点。
  • 如果您仍然解决不了记忆存储加载的问题,不妨考虑一下减少您的中继服务器公布的带宽。 展示较少的带宽意味着您会吸引较少的用户,所以您的中继服务器的规模应该不会变得很大。 请查阅主页中的MaxAdvertisedBandwidth选项。

所有这些都说明,Tor 高速中继确实需要大量内存。高速出口节点占用500-1000 MB内存是不正常的。

特别地,如果您正在使用Debian或Ubuntu,从 Tor 项目的信息库 里安装 Tor 会有许多好处。

  • Your ulimit -n gets set to 32768 high enough for Tor to keep open all the connections it needs.
  • 为 Tor 创建一个用户,所以 Tor 不需要root就能运行。
  • 一个启动脚本被包含在了里面,这样 Tor 就会在开机时自行启动。
  • Tor runs with --verify-config, so that most problems with your config file get caught.
  • Tor 可以捆绑低层级的接口,然后下放权限。

You can run a relay in Windows following this tutorials:

You should only run a Windows relay if you can run it 24/7. If you are unable to guarantee that, Snowflake is a better way to contribute your resources to the Tor network.