用 testdisk 工具试试

不过我之前说的“你说的这个场景下当然是 127 了”确实是错了。我再研究一下原因

我的实验场景虽然得到和你一样的结果，但是有证据说明身份是由服务器端认定的，而不是客户端自称的：

mysqld 开启 skip_ssl 参数，避免加密
strace mysql -h 127.0.0.1 在前面加 strace 观察通信，可以看到下列内容：
connect 建立连接
recfrom 收到服务器的 banner 信息
sendto 只发送了用户名，并没有带有 @127.0.0.1 或者 @localhost 的后缀
然后 recvfrom 收到服务器返回的错误信息 Access denied for user 'root'@'localhost'

@msg7086 access denied 是服务器返回的信息，你说的这个场景下当然是 127 了

骗几次就老实了
而且基本上是成本最低的做法

需要加强软件工程教育

@msg7086 你把 unix domain socket 关闭试试，看 localhost 的用户名还能不能连上

multicast 吧

都是关联企业啊，不影响你写在同一条工作经历里面

人在江湖飘，哪儿能不挨刀

如果能的话说明这个算法的特征过于明显了

猜测可能是 selinux 、apparmor 之类的？

@star7th
首先，原 po 提问的问题是遇到了 localhost 过来的错误登录。mysql 里 localhost 和 127.0.0.1 可不是同一个概念
其次，用代理监听再转发会导致“源 IP”变化，mysql 语境下这种变化会导致登录的其实是另一个用户

@msg7086 这种用 netstat 看不了吧

@star7th mysql 按你建议的这种代理会导致权限错误的，登录不进来

记得选真外企，也就是欧美外企

别选大中华区的人在亚洲开业然后回中国再开子公司那种

不要在系统级、用户级配置（尤其是用户级，简直是经典错误）
要在应用程序启动脚本里设置

@yjxjn 那就恭喜你了，可以入职理想的新工作了

中国要求电子邮件可追溯性
不过你自建的服务器估计没进行过合规设置，也没通过这些评测吧，可能效力并不强

以及，既然邮件是从你这边发出的，对方是否接收了并不在你控制范围内啊，你这边举证什么？

预期在电子邮件上考虑，倒不如考虑一下传输的内容。比如里面是不是放的签字文件的照片或者扫描件？

确实份额小
你发帖子之前我都没听说过这一家