在完全不可能的情况下，阻止 Tor .onion TLD 以避免泄漏，但同时不阻止它以使用户能够做他们想做的事情。
点洋葱泄漏
洋葱顶级域名 (TLD) 是 Tor 特有的域名，对 Tor 之外的世界来说意义不大。如果您尝试使用普通的解析器解析其中的某个域名，会被告知该域名不存在。
如果您向 ISP 的解析器请求这样的主机名，您实际上也向互联网上相当一部分用户宣告了您与该域名通信的意图。DNS 本质上通常不安全，并且通常会被广播给许多不同的参与者。此 IP 地址上的用户打算与这个 .onion 网站进行交互。
因此，对于 Tor 用户来说，绝对不要使用普通的DNS 系统来解析 .onion 名称，这一点至关重要。
解决办法：拒绝他们
为了防止上述 DNS 泄漏，Tor 团队与 IETF 进行了合作，最终发布了RFC 7686 ： “.onion” 特殊用途域名。该规范于 2015 年发布。
本文档详细说明了库和软件应如何处理此类特殊域名。其基本思路是，软件应在很大程度上拒绝解析此类主机名。
卷曲
2015 年 11 月，我们得知了洋葱 RFC 以及它如何指出我们应该过滤这些域名。当时似乎没有人热衷于解决这个问题，所以这个问题被添加到了已知错误文档中。
八年后，这个问题仍然悬而未决，而 curl 也迟迟未采取行动。直到 Matt Jolly 出现，他提交了一份 PR，最终实现了 RFC 中要求的过滤功能。该 PR 于 2023 年 3 月 30 日合并到 curl 中。并于 2023 年 5 月 17 日发布的 curl 8.1.0 版本中正式发布。两年前的事了。
自该版本发布以来，curl 用户不会意外泄露他们的 .onion 使用情况。
使用 Tor 的 curl 用户显然会像往常一样使用 SOCKS 代理来访问 Tor 网络，然后 curl 会让 Tor 服务器进行名称解析，因为这是了解 Tor 和点洋葱域等的实体。
这就是使用代理的好处。像 curl 这样的网络客户端可以将完整的主机名交给代理服务器，让代理服务器完成解析工作，而不是由客户端自己完成。这样可以避免将域名泄露给本地域名解析器。
争议
在 curl 开始支持 Tor 自己推动的 RFC 后不久，具有创造性网络设置的 Tor 用户就意识到了这一点并发表了自己的看法。
一项提案似乎旨在为那些常规名称解析器已受到某种保护且已知正常使用的用户提供基于环境变量的过滤器覆盖方案。环境变量会导致 API 变得非常糟糕，而且讨论最终并未就其他解决方案达成任何共识，因此该提案未能最终落地。
这个问题后来又出现了几次，当时用户遇到了一些问题，但尚未修复或合并解决方案。curl 仍然阻止此域名。通常人们会意识到，只要正确使用 SOCKS 代理，域名就能正常工作，讨论也就到此为止了。
奥纽克斯
本周，Tor 项目宣布了他们的新产品： oniux ：一个命令行实用程序，为使用 Linux 命名空间的第三方应用程序提供 Tor 网络隔离。
在他们介绍这个新工具的介绍网页上，他们甚至使用 curl 命令行展示了它：
$ oniux curl http://2gzyxa5ihm7wid.onion/index.html
（为了便于说明，我决定在此缩短主机名。）
等一下，那个 URL 里不是有 .onion 主机名吗？那么，自从两年前发布 .onion 以来，curl 是怎么处理这些主机名的呢？
正确：图示的命令行仅适用于我们实现 RFC 7686 支持之前的旧版 curl。之前我们尝试在 curl 中执行 Tor 间接建议的操作。所以现在，当我们尝试做正确的事情时，curl 无法与 Tor 自己推出的这个新工具兼容！
至少我们不能说我们的生活确实很平淡。
嘿，这不起作用！
真的没有？跟我们讲讲吧。当然，有人立即就针对 curl提交了一个问题，这完全是理所当然的。这个工具显然就是为这种用例设计的。
那么我们该如何解决这个问题呢？