在暗网自托管
将网站自托管为 Tor onion 服务承诺了强隐私、无暴露 IP 或 DNS、以及即使在 CGNAT 后面也能轻松托管，但也带来了高延迟、难以口头分享的地址，以及协议变更时可能大面积失效的脆弱命名等代价。评论者探讨了实用的设置技巧（Onion-Location 头、端口和套接字选择、监控、私钥备份）、性能策略（减少交互、SSR、内联资源），以及包括钓鱼“前置”、DDoS 和运行出口节点风险在内的安全问题。多人认为 Tor 的设计使其成为比当今监控型网络更干净、更尊重用户的替代方案，而另一些人强调其匿名性和基础设施优先级使 onion 站点天生短暂，不适合作为长期社区的唯一家园。
实际收益与使用场景
- 托管一个 onion 站点可以避免 DNS、证书颁发机构（CA）和公网 IP 暴露；不需要端口转发，而且在 NAT/CGNAT 后面也能很好工作。
- 这在家里托管个人博客和小型服务时很受欢迎，并且 IP 隐私是“天生如此”。
- 有些人也部分因为说自己在运行一个暗网网站时的“酷感”而喜欢这么做。
设置、工具与在线时间
- 基本的 Tor 隐藏服务被描述为相当直接；主要阻力是对非技术用户来说 CLI 的复杂性。
- 像 OnionShare 这样的 GUI 工具，以及会自动生成隐藏服务的项目，旨在让“放一个文件夹，就得到一个网站”的工作流成为可能。
- 通常建议使用 Onion-Location 头，这样 Tor 浏览器可以自动切换到 onion 副本。
- 在线时间应该通过标准监控来处理；否则，宕机可能会很长时间都没人注意到。
- 新建/重启后的 onion 服务可能需要一段时间才会可达；在 Tor 被封锁的地方则需要桥接（obfs4、Snowflake）。
安全、匿名性与信任
- 隐藏服务不会让你变成出口节点；你不可能“意外”运行一个出口。把出口节点和隐藏服务结合起来是不被建议的。
- 关于政府是否能可靠去匿名化 Tor 的争论一直存在：有些人坚持通常只会利用操作失误；另一些人则推测存在未公开的能力。
- 站点前置（恶意 onion 代理）是一个已知问题；缓解方式包括站外地址验证、把真实 URL 的部分内容编码进 CAPTCHA、信任链，以及炫酷（vanity）onion 地址。
- 备份 onion 私钥至关重要；丢失它就必须换一个新地址。
性能与架构选择
- 延迟很高；静态站点或主要采用 SSR 的站点表现最好。
- 建议：尽量减少 HTTP 请求、保持连接存活、内联 CSS、UI 尽量用 CSS 而不是 JS、避免前端过于“碎嘴”。
- 对于 base64 嵌入资源的看法不一：在 Tor 上有帮助，但在现代明网中则不那么有用，因为缓存和 HTTP/2 更占优势。
- HTTP/2 可以提升性能，但需要 TLS；.onion 没有免费的证书，因此有人讨论把自签名证书视为对 onion 来说可信。
限制、风险与短暂性
- onion 地址很难记，也很难口头分享，而且没有人类可读意义。
- v2 onion 的弃用被引用为“所有 .onion 上的内容都是短暂的”这一观点的证据；一些人认为这是必要的安全进步，另一些人则认为这是一种规模上独一无二、灾难性的链接腐烂。
用户体验、可访问性与更广泛的 Web 语境
- Tor 往往更慢，尤其是对于“碎嘴”的网站，不过也有人表示一旦电路建立起来，速度可以接受。
- 非技术用户面临陡峭的学习曲线，但也有人认为学习核心命令是合理的要求。
- 与“明网”的比较批评了由广告/监控驱动的设计、激进的反机器人/CDN 前端，以及为 AI 训练而抓取数据；onion 站点则被赞为精简、适合文本、且没有追踪。
- 有些人更喜欢“自由网络（free web）”而不是“暗网（dark web）”这个说法。