Here's how I found it. I analysed the withduo.cap again and found a key and only network action of the test server when it's lagging was to DNS query for its own hosename but could not get the answer from its DNS server:
![](https://img-blog.csdnimg.cn/20200908112933600.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zOTgzMzUwOQ==,size_16,color_FFFFFF,t_70)
![](https://img-blog.csdnimg.cn/20200908113029944.png)
So, I wonder whether it is resolving its own hostname(
gghjjyy) to ip address that makes it waits for 10s.
Here's the hostname resolving setting:
[dddd@gghjjyy~]$ cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
......
hosts: files dns myhostname
#
# /etc/nsswitch.conf
#
......
hosts: files dns myhostname
......
But /etc/hosts did not contained the record: 158.87.1.16
gghjjyy:
[dddd@gghjjyy ~]$ sudo cat /etc/hosts
[sudo] password for zhangyu:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
[sudo] password for zhangyu:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
So the previous host resolving behavior was waiting until hosts file fails, DNS query fails and then using myhostname.
I added 158.87.1.16
gghjjyy to /etc/hosts and then the 2FA login only takes 2-3 seconds.