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 · 137 天前 · 3003 次点击
    这是一个创建于 137 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    现在很苦恼……

    第 1 条附言  ·  136 天前
    现在是整个网段的虚拟机都不通,也没有设置相应的代理或者 HOSTS 。

    应用本身是好的。

    用 curl -v 之后,第一行是


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

    第二行有点奇怪,是 TCP_NODELAY SET

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

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

    我推荐这个命令:
    sudo nethogs -d 1 -v 4 -l
    可以看到你当前网络流量开销大的进程是哪一个
    xiangwan
        11
    xiangwan  
       136 天前
    检查 web 服务器起来没有
    aaa5838769
        12
    aaa5838769  
       136 天前
    使用 nmap 命令,看下端口是否通的
    wudao95278
        13
    wudao95278  
       136 天前
    # 编辑
    vi /etc/sysctl.conf
    # 添加、报错
    net.ipv4.tcp_timestamps = 0
    # 生效
    sysctl -p
    orisine
        14
    orisine  
       136 天前
    有可能虚拟机 dns 问题
    ssbg2
        15
    ssbg2  
    OP
       136 天前
    嗯,谢谢大家,我这会再去试试看。
    NUT
        16
    NUT  
       135 天前
    本地上 telnet 看看接口通了吗
    doveyoung
        17
    doveyoung  
       135 天前
    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
       135 天前
    @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  
       135 天前
    看 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
       134 天前
    @doveyoung 嗯,谢谢了,我再想想看。
    ssbg2
        21
    ssbg2  
    OP
       134 天前
    @doveyoung 嗯,顺着您的思路,我查看了下 mtu 和相关的设置,都是正常的,包括使用 netstat -s |grep reject 查看了下,发现因为时间戳拒绝的包很多。
    最终发现了问题的原因:之前这个 nginx 服务器上多绑定了一个 18 段的 IP,然后更改了网络环境后,这个网卡的配置却一直没有被删除,所以就是您说的 nginx 服务器找不到正确的路径回复给客户端,导致了握手失败。
    删除这个 ip 配置后,一切正常了。
    谢谢您了!
    v2clay
        22
    v2clay  
       127 天前 via Android
    我去,生产环境下,我们也遇到过,配双网卡导致的。这个是低级错误。用 router 命令查路由表
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2871 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 10:28 · PVG 18:28 · LAX 02:28 · JFK 05:28
    ♥ Do have faith in what you're doing.