洋葱服务的性能问题出在服务器端：毫秒去了哪里，运营者真正能调什么
洋葱站点一慢，人们的第一反应是怪 Tor 网络。这只对了一半。隐藏服务从不与访客直接对话，每条连接都由双方各自选出的中继拼接而成；但相当一部分等待时间是在服务自己的机器上制造的——在 Tor 维护 Web 后端前面那套管道的方式里。分清哪一半是哪一半，决定了调优究竟有帮助，还是只是把锅挪了个位置。
毫秒去了哪里
Tor Project 的协议概述把一条完整的洋葱连接算作六个中继：客户端选三个，服务端选三个，在会合点（rendezvous point）处拼接，随后该点"只是转发（端到端加密的）消息，在客户端与服务之间来回传递"（Tor Project，洋葱服务协议）。在那条电路存在之前，好几个往返已经花掉：客户端从分布式哈希表取回服务的签名描述符，建一条通往某个引入点的路径，再协商会合。这些都不是后端时间，却全部落在访客的秒表上。 服务端还背着客户端不用付的固定开销。引入点始终挂着来自服务的长期匿名化电路，而 Tor 手册把默认池定为三个引入点，v3 服务最多可扩到二十个。这些中继是服务唯一的地址，所以不能悄悄消失：一个引入点失效，服务就得再建一条三跳电路并重新发布签名描述符——这些工作以更冷、更慢的首屏加载呈现出来。运营者真正控制什么
Tor 暴露的旋钮清单很短，比性能圈的各种传说要窄：- 加密余量。引入与会合产生的握手由一池加密工作线程解密；手册把 NumCPUs 描述为"同时用多少个进程来解密 onionskin 及其他可并行的操作"。CPU 饿着肚子的服务，恰恰在运营者能修的地方显得慢。
- 引入点池大小。HiddenServiceNumIntroductionPoints 默认为三；更多引入点会把引入请求摊到更多中继上，代价是更多常驻电路。
- 电路新鲜度。MaxCircuitDirtiness 默认十分钟，手册还注明：对隐藏服务而言，计时从电路最后一次承载流量算起。调高它减少重建；调低它用更多构建换更新鲜的路径。
- 软件版本。拥塞控制随 2022 年的 Tor 0.4.7 落地，Tor Project 说得很直白："使用已升级到 0.4.7 的出口或洋葱服务的 Tor 0.4.7 及以上版本用户将体验到更快的性能"——旧版本上的洋葱服务把每位访客都锁在传统流控里（Tor Project 博客）。
单跳的诱惑
Tor 这个角落里最古老的性能争论是：服务端到底需不需要三跳保护。Proposal 260 由包括 Roger Dingledine 和 Paul Syverson 在内的团队于 2015 年起草，并在 Tor 0.2.9.3-alpha 中实现，它描述了"会合式单跳洋葱服务"——"用服务端的位置隐私换取更好的性能、可靠性与可扩展性"：到引入点和会合点走单跳电路，整条路径砍到"4 而非 6"个中继。这个开关至今仍在：HiddenServiceSingleHopMode 被文档标注为实验性、非匿名；它让服务器"容易被定位"，而"客户端保持匿名"。 这笔交易毫不含糊。单跳洋葱保住自己的 .onion 地址和访客的匿名，却交出运营者自己的位置隐蔽——而且该提案的作者警告过，洋葱服务每多一种形态，"匿名集就多一分分裂"。因此默认设计活了下来：单跳只是留给能接受暴露的运营者的可选工具，这个判断 Tor 有意留在协议之外。为什么大型站点都跑调优过的后端
长命的洋葱站点——搜索引擎、镜像、目录——都收敛到同一个形态：薄薄的 Tor 前端，刻意静态化或缓存化的后端，负载摊到多个实例上。Proposal 260 甚至提到，会合式单跳服务"可以在多个会合后端之间做负载均衡"。这些都不会缩短路径；它只是把运营者拥有的那一段压到最小，让六中继之旅成为唯一值得计较的等待。Tor Metrics 通过从充当会合点的中继统计中推断来测量洋葱流量——可见的负载恰恰就住在那一层（Tor Metrics）。什么修得了，什么修不了
"由于洋葱服务路径的长度是出口路径的两倍以上（因此电路延迟也是两倍以上），洋葱服务的吞吐量将永远不到出口吞吐量的一半。"（Proposal 324）运营者修得了加密余量、引入点池大小、软件版本和后端重量；修不了路径长度、当天的电路建立耗时、中继拥塞，也修不了客户端自己的守卫轮换。诚实的解读是：首次无缓存加载花上几秒并不代表站点坏了——那是描述符、引入与会合在足额买单；而热电路上的后续请求应当贴近后端自身响应时间加网络传输。 如果首页之后仍然慢，运营者多半还有得可调。如果只在午夜高峰显得慢，那是网络在当班，不是后端——我们在之前关于洋葱延迟波动的实地记录里写过这个模式。服务端的收益真实但有边界：调好 torrc 名下的东西，让源头保持轻盈，并且别再指望路径比协议规定的更短。