把自己的网站同时以 Tor 隐藏服务的方式提供，技术上只需要一台装好 Tor 的服务器、一段 torrc 和一段 nginx 配置。核心动作是 HiddenServiceDir 指向一个 Tor 自己拥有的专用目录，启动后从该目录的 hostname 文件里拿到那串 56 字符的 onion 地址，再用 HiddenServicePort 把它转发到只监听 127.0.0.1 的本地端口。这么做带来的收益是服务端不暴露公网 IP、不需要 DNS 和证书机构，代价是延迟明显变高、受众极小，而且绝大部分宣传里的匿名性只在协议层成立，实际强度取决于宿主机怎么运维。
onion 地址是怎么来的
隐藏服务的地址不是随机字符串，它由服务端的公钥派生。v3 地址固定 56 个字符，服务器持有对应的私钥，客户端用洋葱路由的三次握手建立连接，全程端到端加密。证书体系和域名解析这两件事都被绕开了，不需要 CA 签发，也不需要任何人解析你的域名。
这也意味着私钥就是站点的所有权证明。hostname 文件丢失，站点对客户端来说就是换了另一个站，所以备份这个文件比备份网站内容更要紧。
完整配置步骤
Tor 的配置写在 /etc/tor/torrc，两行就够。
HiddenServiceDir /var/lib/tor/blog/
HiddenServicePort 80 127.0.0.1:8080重启服务，然后读地址。
sudo systemctl restart tor@default
sudo cat /var/lib/tor/blog/hostname这里有一个高频踩坑点。Tor 要求 HiddenServiceDir 由它自己的用户拥有，权限 700，不能把目录指向站点文件本身。很多教程让读者把 web root 直接填进去，Tor 会拒绝启动，报错信息也不够显眼。正确的做法是两件事分开，Tor 用一个专用目录，网站文件放在另一个路径。
nginx 侧只监听回环地址，不碰公网端口。
server {
listen 127.0.0.1:8080;
server_name xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion;
root /srv/tor.example.com;
index index.html;
error_page 404 /404/index.html;
location / { try_files $uri $uri/ =404; }
}文中强调这里不要 TLS、不要 HTTP/2、不要 QUIC。Tor 本身就是纯 TCP 通道并且自带加密，再套一层 TLS 只会浪费 CPU，证书也没法验证。
静态站点生成器的构建命令要单独出一份，因为 baseURL 必须改成 onion 地址，否则生成的资源引用还指向明文网址。每次推送分别为明文网络和 Tor 网络各构建一份，用 rsync 送到各自的 web root。
收益到底有多少
协议层能确认的收益是三条。服务端不暴露公网 IP，端口扫描打不到你。没有 DNS，也就没有域名注册信息和解析记录。没有 CA，也就没有证书透明日志这一层公开可查的注册信息。客户端看到的 onion 地址由你的公钥决定，中间节点无法篡改。
这里要区分清楚文中说法和实际能保证的东西。有一段常见表述是，Tor 让流量经过成千上万台志愿者服务器，因此没有任何一方能把你的身份和行为关联起来。这句话在协议设计上成立，在运维层面远不完整。托管商相同、活动时间窗口重叠、内容在明文网络另有副本，任意一条都能把两边的站点关联起来。洋葱路由保护的是网络层的观察者，不保护宿主机层面的日志、时间戳和流量模式。
这篇文章本身没有给出威胁模型分析，也没有讨论性能开销、法律边界、私钥备份与轮转、入侵检测。这些缺口在实际部署前都要自己补。
适合谁，不适合谁
值得做的场景有几类。需要在实体地址保密的前提下提供服务，比如消息源或举报渠道。想给用户一条绕开 DNS 污染的访问路径。安全研究者想在隔离环境里做测试。
不值得做的场景也很清楚。追求速度，Tor 的多次跳转会把延迟拉到常规访问的数倍。把它当成匿名性的全部保证，宿主机和运维层面的关联一样会暴露身份。内容已经在明文网络公开，收益基本只有一条备用访问路径。
常见问题
要把整个站都搬过去吗？ 不必。可以只放一份内容，甚至只做一个入口页。
onion 地址会被搜索引擎收录吗？ 主流搜索引擎不索引 Tor 网络，发现依赖用户主动获取地址。
该选 V3 还是更早版本？ V3。地址更长、加密更强、校验方式也更可靠，早期版本已不推荐。
私钥泄露了怎么办？ 立刻停掉服务，清空隐藏服务目录，重新生成一套，同时通知用户地址已变更。