V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
NGINX
NGINX Trac
3rd Party Modules
Security Advisories
CHANGES
OpenResty
ngx_lua
Tengine
在线学习资源
NGINX 开发从入门到精通
NGINX Modules
ngx_echo
ssbg2
V2EX  ›  NGINX

奇怪,一个服务,用 IP 访问正常,也能 ping 通(IP 和域名都可以),但是用 curl 就是不行

  •  
  •   ssbg2 · 2021-07-19 17:56:34 +08:00 · 6765 次点击
    这是一个创建于 983 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,公司一个长期运维的项目,有两个 IP 网段不同的集群,通过 nginx 做了反向代理,之前是正常的,最近突然有台虚机访问服务有问题了,查了一圈发现,用 IP 加端口可以通(临时开了下策略,后面还是要去掉的),ping 域名也可以,但是用 curl 发 get 请求就不行了,显示超时,curl 给别的服务发请求都正常。

    然后用另外一个网段的机器操作,也是正常的。

    看 nginx 日志,请求就没有进去。

    现在很苦恼……

    第 1 条附言  ·  2021-07-20 14:53:35 +08:00
    现在是整个网段的虚拟机都不通,也没有设置相应的代理或者 HOSTS 。

    应用本身是好的。

    用 curl -v 之后,第一行是


    Trying xxx.xxx.xxx.xxx:443 ....

    第二行有点奇怪,是 TCP_NODELAY SET

    然后等一会就超时了,提示 Closing connection 0……
    第 2 条附言  ·  2021-07-20 16:14:58 +08:00
    @orisine 如果是 DNS 问题,那就不应该解析到域名绑定的公网 IP 才对……
    @wudao95278 试过了,没有效果……
    @aaa5838769 端口也是通的
    @guanyin8cnq12 显示 80 443 open
    @xiangwan 服务是正常的
    @zzyphp111 能监测到流量,那说明应该是 nginx 哪个地方有问题了……
    23 条回复    2021-12-16 18:26:13 +08:00
    internelp
        1
    internelp  
       2021-07-19 17:59:11 +08:00
    看下终端是否配置了代理呢
    milk97
        2
    milk97  
       2021-07-19 18:15:13 +08:00
    看下 /etc/hosts,是不是指定了域名的 IP
    AngryPanda
        3
    AngryPanda  
       2021-07-19 18:21:50 +08:00
    是否设置了环境变量 HTTP_PROXY 之类?
    darknoll
        4
    darknoll  
       2021-07-19 18:28:41 +08:00
    加个-L 试试?
    lasuar
        5
    lasuar  
       2021-07-19 19:15:35 +08:00
    curl 加-v 看看通信过程
    falcon05
        6
    falcon05  
       2021-07-19 19:28:16 +08:00 via iPhone
    是不是有 waf 把 curl 默认 ua 拦截了,换个 ua 试试
    guanyin8cnq12
        7
    guanyin8cnq12  
       2021-07-19 19:29:57 +08:00
    这是有拦截啊 ,用 tcping,ping 80
    zzyphp111
        8
    zzyphp111  
       2021-07-19 20:18:47 +08:00
    给你推荐下命令( mac | linux ):

    sudo tcpdump -i en0 -n port 80 -vv
    可以看到当前机器和外部网络的所有流量交互,都是 ip 到 ip 的,非常详细,顺便还可以看到那些软件窃取了你的隐私上报给第三方。
    Smash
        9
    Smash  
       2021-07-19 20:23:46 +08:00
    @zzyphp111 怎么把 ip 对应到程序呢?没有打印进程信息.
    zzyphp111
        10
    zzyphp111  
       2021-07-19 20:31:01 +08:00   ❤️ 1
    @Smash #9 当然,肯定有人有需求看下 当前流量对应是哪个进程

    我推荐这个命令:
    sudo nethogs -d 1 -v 4 -l
    可以看到你当前网络流量开销大的进程是哪一个
    xiangwan
        11
    xiangwan  
       2021-07-19 21:20:56 +08:00
    检查 web 服务器起来没有
    aaa5838769
        12
    aaa5838769  
       2021-07-19 21:41:28 +08:00
    使用 nmap 命令,看下端口是否通的
    wudao95278
        13
    wudao95278  
       2021-07-20 07:35:38 +08:00
    # 编辑
    vi /etc/sysctl.conf
    # 添加、报错
    net.ipv4.tcp_timestamps = 0
    # 生效
    sysctl -p
    orisine
        14
    orisine  
       2021-07-20 09:33:24 +08:00
    有可能虚拟机 dns 问题
    ssbg2
        15
    ssbg2  
    OP
       2021-07-20 13:25:26 +08:00
    嗯,谢谢大家,我这会再去试试看。
    NUT
        16
    NUT  
       2021-07-21 08:55:25 +08:00
    本地上 telnet 看看接口通了吗
    doveyoung
        17
    doveyoung  
       2021-07-21 10:17:23 +08:00
    1. 虚拟机上 curl -v
    2. 虚拟机上 tcpdump
    3. nginx 上 tcpdump

    “IP 加端口可以通”,是 curl https://IP:port 吗,还是 telnet ?
    还可以检查一下 nginx 上 /proc/sys/net/ipv4/tcp_tw_recycle 的值,值是 1 的时候会影响客户端 nat 后的访问,
    ssbg2
        18
    ssbg2  
    OP
       2021-07-21 16:04:09 +08:00
    @NUT 谢谢您,我测试了,是通的。

    @doveyoung
    谢谢您,1 、虚拟机上用 curl -v,结果就是
    Trying xxx.xxx.xxx.xxx:443 ....
    TCP_NODELAY SET
    然后等一会就超时了,提示 Closing connection 0……

    2 和 3 、客户端虚拟机上( 18.200 )使用 curl 发送 get 请求,输出情况是这样:
    tcpdump -n port 443 -i ens192 and host 192.168.16.218 -vv
    tcpdump: listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
    15:52:24.481160 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.16.218.https > 192.168.18.200.41034: Flags [S.], cksum 0x3dcd (correct), seq 3835702915, ack 1032333183, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:24.481209 IP (tos 0x0, ttl 64, id 9141, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:25.482070 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.16.218.https > 192.168.18.200.41034: Flags [S.], cksum 0x9963 (correct), seq 3851342334, ack 1032333183, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:25.482136 IP (tos 0x0, ttl 64, id 9552, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:27.485907 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.16.218.https > 192.168.18.200.41034: Flags [S.], cksum 0xc9fe (correct), seq 3882655621, ack 1032333183, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:27.485972 IP (tos 0x0, ttl 64, id 10776, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:31.489995 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.16.218.https > 192.168.18.200.41034: Flags [S.], cksum 0x1633 (correct), seq 3945222038, ack 1032333183, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:31.490057 IP (tos 0x0, ttl 64, id 13410, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:39.505889 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.16.218.https > 192.168.18.200.41034: Flags [S.], cksum 0xcf03 (correct), seq 4070477646, ack 1032333183, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:39.505945 IP (tos 0x0, ttl 64, id 19809, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    然后 nginx 上( 16.218 )使用 tcpdump 监听到的日志是这样:
    tcpdump: listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
    15:52:25.568684 IP (tos 0x0, ttl 63, id 6305, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:25.569331 IP (tos 0x0, ttl 63, id 9141, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:26.569602 IP (tos 0x0, ttl 63, id 6306, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:26.570270 IP (tos 0x0, ttl 63, id 9552, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:28.573661 IP (tos 0x0, ttl 63, id 6307, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:28.574321 IP (tos 0x0, ttl 63, id 10776, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:32.577927 IP (tos 0x0, ttl 63, id 6308, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:32.578604 IP (tos 0x0, ttl 63, id 13410, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:40.594269 IP (tos 0x0, ttl 63, id 6309, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:40.594906 IP (tos 0x0, ttl 63, id 19809, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:52:56.643423 IP (tos 0x0, ttl 63, id 6310, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:52:56.644167 IP (tos 0x0, ttl 63, id 33143, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0
    15:53:28.709344 IP (tos 0x0, ttl 63, id 6311, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [S], cksum 0x513e (correct), seq 1032333182, win 29200, options [mss 1400,nop,nop,sackOK,nop,wscale 7], length 0
    15:53:28.709799 IP (tos 0x0, ttl 63, id 48301, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.18.200.41034 > 192.168.16.218.https: Flags [R], cksum 0x03e1 (correct), seq 1032333183, win 0, length 0

    以上都是用域名请求的,客户端能解析到实际的内网 IP 且服务端能监听到请求,我认为网络层是通的,现在就是没有发送到 nginx 里。

    使用 curl 对 IP 请求是这样请求的: https://IP:port/assets,可以正常得到返回信息。
    另外就是 /proc/sys/net/ipv4/tcp_tw_recycle 这个值是 0
    doveyoung
        19
    doveyoung  
       2021-07-21 17:51:36 +08:00
    看 nginx 抓包的信息,nginx 收到了请求但是没有回复给客户端,客户端一直在 seq 1032333183 / 1032333182
    我暂时只想到这几点
    1. 客户端或服务端的 MTU 值不合理
    2. 类似 /proc/sys/net/ipv4/tcp_tw_recycle =1 的原因,但是你检查后值是 0,可以暂时排除
    3. nginx 本应该回复给 192.168.18.200 的包,回复给了错误的 IP,在 openstack 里的虚拟机使用了浮点 IP 后经常出现这种问题
    4. emmmmm 想不到了 ( :(|
    ssbg2
        20
    ssbg2  
    OP
       2021-07-22 08:38:38 +08:00
    @doveyoung 嗯,谢谢了,我再想想看。
    ssbg2
        21
    ssbg2  
    OP
       2021-07-22 09:49:05 +08:00
    @doveyoung 嗯,顺着您的思路,我查看了下 mtu 和相关的设置,都是正常的,包括使用 netstat -s |grep reject 查看了下,发现因为时间戳拒绝的包很多。
    最终发现了问题的原因:之前这个 nginx 服务器上多绑定了一个 18 段的 IP,然后更改了网络环境后,这个网卡的配置却一直没有被删除,所以就是您说的 nginx 服务器找不到正确的路径回复给客户端,导致了握手失败。
    删除这个 ip 配置后,一切正常了。
    谢谢您了!
    v2clay
        22
    v2clay  
       2021-07-29 08:19:48 +08:00 via Android
    我去,生产环境下,我们也遇到过,配双网卡导致的。这个是低级错误。用 router 命令查路由表
    asuraa
        23
    asuraa  
       2021-12-16 18:26:13 +08:00
    卧槽 我遇到了一个更诡异的事情...
    tcping 正常
    ping 正常
    http 抓包 服务端有来有回 客户端只有去没有回 防火墙都检查了 没问题 服务器也重装了
    就是不知道为毛
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3267 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 11:52 · PVG 19:52 · LAX 04:52 · JFK 07:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.