阿里云服务器网络问题咨询

[anyforever]

现象：所在阿里云服务器的程序（在别的机房稳定运行至少两年）， php 环境，使用 curl 访问又拍接口，非常高几率（有正常上传成功的记录）的 HTTP 返回状态码为 0 。

以下为在服务器端使用 traceroute 和 mtr 工具测试又拍接口的链路返回情况。以前没怎么接触过网络相关的调试，一般只是简单的用下 ping ，虽然百度了下这两个命令的结果解读，但是对理解的不是很有底，所以还是请有经验的朋友帮忙解读一下下面的测试结果。

$ traceroute v0.api.upyun.com traceroute to v0.api.upyun.com (111.206.105.226), 30 hops max, 60 byte packets 1 11.242.177.50 (11.242.177.50) 0.848 ms 11.242.176.142 (11.242.176.142) 0.932 ms 11.242.158.114 (11.242.158.114) 0.905 ms 2 11.242.177.46 (11.242.177.46) 0.829 ms 11.242.157.218 (11.242.157.218) 0.848 ms 11.242.177.62 (11.242.177.62) 0.873 ms 3 42.120.243.90 (42.120.243.90) 2.587 ms 42.120.243.86 (42.120.243.86) 2.500 ms 42.120.243.182 (42.120.243.182) 3.477 ms 4 123.56.34.21 (123.56.34.21) 1.898 ms 101.200.109.150 (101.200.109.150) 44.165 ms 123.56.34.5 (123.56.34.5) 1.958 ms 5 * * * 6 61.51.116.225 (61.51.116.225) 4.663 ms 3.004 ms 123.126.8.37 (123.126.8.37) 1.434 ms 7 124.65.61.177 (124.65.61.177) 4.113 ms 123.126.8.218 (123.126.8.218) 6.914 ms 124.65.61.173 (124.65.61.173) 5.466 ms 8 61.51.247.186 (61.51.247.186) 1.742 ms 123.126.8.218 (123.126.8.218) 6.888 ms 61.51.247.186 (61.51.247.186) 1.757 ms 9 61.51.247.186 (61.51.247.186) 2.484 ms 2.376 ms 61.148.163.194 (61.148.163.194) 2.982 ms 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

$ traceroute -r v0.api.upyun.com traceroute to v0.api.upyun.com (111.206.105.226), 30 hops max, 60 byte packets connect: Network is unreachable

使用 trace 测试，链路不通。阿里客服说上面工具不准，让使用 mtr 测试，发了测试结果给他们，他们反馈说，网络是正常的。

$ mtr -c 20 -n --report v0.api.upyun.com HOST: iZ2zeienl21fksruegqz Loss% Snt Last Avg Best Wrst StDev

1. 11.242.176.146 0.0% 20 0.9 1.0 0.9 1.9 0.2
2. 11.242.176.146 0.0% 20 0.8 0.8 0.8 1.0 0.0
3. 106.11.37.34 0.0% 20 1.8 1.8 1.0 3.1 0.6
4. 123.56.34.26 0.0% 20 1.7 1.8 1.7 2.8 0.3
5. 61.49.137.53 70.0% 20 13485 14085 13485 14823 505.6
6. 123.126.8.37 0.0% 20 2.2 2.2 2.2 2.3 0.0
7. 123.126.8.113 0.0% 20 5.2 4.6 3.3 6.6 1.1
8. 202.106.34.54 0.0% 20 5.6 5.2 3.1 7.0 1.3
9. 61.51.247.186 0.0% 20 2.6 2.6 2.5 2.6 0.0
10. 61.49.163.78 0.0% 20 4.0 4.5 3.9 8.4 1.0
11. ??? 100.0 20 0.0 0.0 0.0 0.0 0.0
12. 111.206.105.226 0.0% 20 3.1 3.2 3.0 3.7 0.1

在多个测试结果中，第 5 跳，均有不同程度的丢包。 11 跳均是 100%，这个到底能不能到达目标服务器？或者是网络的哪个节点有问题？

找了个国外 VPS 试了下

$ mtr -c 20 -n --report v0.api.upyun.com Start: Wed Feb 22 10:56:50 2017 HOST: apple Loss% Snt Last Avg Best Wrst StDev

1.|-- 107.182.184.23 0.0% 20 0.0 0.1 0.0 0.2 0.0 2.|-- 173.254.225.65 0.0% 20 0.4 1.3 0.3 16.9 3.0 3.|-- 96.44.180.97 0.0% 20 0.3 0.4 0.2 1.1 0.0 4.|-- 213.248.71.105 0.0% 20 0.5 1.0 0.4 3.4 0.5 5.|-- 213.248.101.50 0.0% 20 3.4 4.8 1.5 11.7 2.9 6.|-- 129.250.5.29 0.0% 20 3.6 5.3 1.3 13.8 3.5 7.|-- 128.242.180.190 0.0% 20 3.4 4.1 3.4 10.8 1.7 8.|-- 10.16.18.98 0.0% 20 11.4 6.7 3.5 11.4 2.7 9.|-- 165.254.60.146 0.0% 20 1.1 3.7 0.7 8.7 2.5

[ovear]

网络中的节点不一定会回应你的 ICMP

[linbiaye]

看最后一跳，@overa 说的对，有些设备就是不回 icmp 。

[linbiaye]

curl 返回的状态码为 0 这个问题你需要两边都抓包看。能返回状态码就不是 tcp/网络的问题， curl 是拿到了 http response 的。

[anyforever]

@ovear
@linbiaye 嗯。谢谢。我再想想其它办法测试这个。