在 Dante 中选择 SOCKS5 认证方式
了解 Dante 如何选择客户端提供的 SOCKS5 认证方式，以及方式顺序如何改变客户端所体验到的策略。
在 SOCKS5 中，认证在客户端发送目标请求之前完成协商。因此，早期的凭据失败与代理之后的 FTP、HTTPS 或其他应用程序失败是不同性质的事件。
客户端的问候消息会列出它支持的认证方式。服务器从该列表中选择一种方式，并把选择结果发回。值 0xff 表示没有任何提供的方式可以接受，连接必须关闭。客户端并不会在密码失败后简单地把服务器端的每种方式都试一遍。
Dante 的顺序控制什么
Dante 1.4.x 把协议级设置称为 socksmethod。其文档说明这些方式按优先顺序列出。对于同时允许两种方式的策略，当客户端提供用户名/密码时，该声明会优先选择用户名/密码：
socksmethod: username none把列表反转后，当两种方式都被提供时会优先选择未认证访问：
socksmethod: none username这些是替代性的方式声明，而不是完整的服务器配置。监听接口、允许的客户端、目标规则以及任何针对具体规则的认证约束仍然重要。
允许 none 有一个具体后果：只提供“无认证”的客户端可能在适用规则下被接受。把 username 放在首位并不会把包含 none 的列表变成要求每个人都提供密码。
先选择要求
如果每个被允许的客户端都必须用用户名/密码认证，请在全局规则和适用规则中一致地配置这一要求，而不是把 none 当作通用的兼容性修复加进去。如果匿名访问是为一组受限客户端刻意保留的，就要把该组及其允许的目标明确写出来。
Dante 还有 clientmethod，它涉及 TCP 客户端连接时、SOCKS 协商之前所执行的检查。它是与 SOCKS5 问候中交换的方式不同的一个层。使用较旧的 method 关键字的配置片段应当对照所安装的 Dante 版本的手册来阅读。
当两个客户端表现不同时，比较各自提供了什么、Dante 选择了什么，以及所选方式的子协商是否成功。然后再检查 SOCKS 目标回复。这一顺序可以在不把每次失败都归咎于 FTP、也不盲目更改服务器认证策略的情况下，找出缺失的凭据回调。
最后，SOCKS5 的用户名/密码认证并不会加密密码交换。当这些凭据需要保密时，请使用得到适当保护的传输或网络。