M-209如何安装

Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 怎么获得云币？是不是回复帖子会有？ ------------------------- Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 谢谢 ------------------------- 第二步，安装完之后，没有80、9000端口 第二步，安装完之后，没有80、9000端口，这个是什么原因，该怎么解决？求助 ------------------------- 回 12楼larryli的帖子 第二步，安装完之后，没有80、9000端口，这个是什么原因，该怎么解决？求助啊 ------------------------- 回 145楼training的帖子 楼主好，感谢您的解答，我刚看到您的回复。想问一下，有没有pw论坛的安装教程？，还有，往后是不是重装系统后，也可以搭建WordPress？多谢 ------------------------- Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 楼主你好，WordPress我搭建好了。其中遇到过一个问题，已经解决，向您汇报一下，第一步安装“一键安装包”的时候没有安装成功，后来是将系统换成了“centos”,然后才安装成功，所以，ECS的操作系统最好选用这个。 最后，我已经把站点安装好了，希望楼主后续发一些比较适合菜鸟的WordPress应用技巧，多谢。 ------------------------- 回 209楼training的帖子 楼主大大好，我也遇到了198楼那哥们遇到的问题，站点都建好了，而且用  http:/IP地址/wordpress/   可以打开站点，但是，直接输IP地址或者域名，打开后是403 Forbidden  ，请问这个是什么原因？是不是因为没有进行域名绑定？应该怎么操作。我的域名是今天刚通过备案的，才发现这个问题。诚心求教，多谢！ ------------------------- 回 198楼伊奇的帖子 哥们，你的问题解决了吗？403 Forbidden 错误，我也遇到了 ------------------------- 回 197楼上云服务的帖子 又遇到问题了，直接输入域名，显示403 Forbidden，是不是需要域名绑定？我去搜了下相关教程，看的云里雾里，希望能给出后续建站的一些指导。多谢 ------------------------- 回 217楼training的帖子 多谢楼主耐心讲解。是不是还可以修改nginx配置文件，把根目录修改成www下面的wordpress?我看您发的第三个视频有修改nginx的过程，是把根目录www/phpwind改成了www。（我不知道说的对不对，这是我理解的，完全小白啊） ------------------------- Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 楼主大大好，我按照您的指导，将那个文件放在了www下面，确实可以打开，但是，网址那一栏还是显示的  http://域名/wordpress. 之后，我修改了nginx配置，将根目录（应该是根目录吧）改成了www/wordpress，之后，输入域名，确实能打开，但是，点击返回首页或者登陆，都失败。 我又将nginx配置还原，就是根目录那块儿，我重新按照 http://域名/wordpress.输入网址，能打来，然后登陆，修改了 wordpress的设置，就是网址 之后，我再修改nginx配置，将根目录改成了www/wordpress，之后，浏览器输入域名，可以打开，然后正常登陆。 不知道这样对不对。我对那个代码完全懵逼，就是觉得从逻辑上应该是域名指向某个文件夹，也就是根目录，具体怎么操作，都是照猫画虎，跟着视频走的。 我的网站是www.pajidy.com 我想问下，为什么首页那个建站时间没有显示，而且导航栏去哪了。这些应该是琐碎的操作了，我就是吐槽一下 ------------------------- 回 172楼training的帖子 大神，我按照171楼和172楼的方法，做了修改，为什么最后登陆phpmyadmin的时候显示 “#1045 无法登录 MySQL 服务器” 密码都是对的 我也去百度了一下，是不是修改phpmyadmin的文件夹地址之后，权限出现了问题？ 该怎么解决啊，多谢 ------------------------- 回 228楼风愿的帖子 是不是你之前的安装有问题？还有就是选择合适的操作系统 ------------------------- Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 关于出现连接数据库错误，我找了一个教程，不知道是不是这么解决，粘贴出来。（我的网站是：啪几网www.pajidy.com） 以前一直用虚机，这次改用了阿里云服务器，因为这个站点纯粹就是个人喜好建立的，所以主机配置比较低，单核1G，1M独立外网带宽，环境是centos6.5 64位，nginx mysql 位安装管理面板，自己对这方面也完全是白丁，整个服务器环境的搭设全部按照阿里云官方的教程进行，整体弄完后，把自己的WORDPRESS搬上去，也还算顺利。不过运行了半个多余突然出现问题。打开网页的时候显示“建立数据库连接时出错”，通过后台链接MYSQL发现报错无法连接，自己也不太懂，就直接重启了服务器，一切正常。不过出现这种问题心理多少有些担忧，就在后台通过看了下进程，一看发现一个php-fpm的进程有很多子进程，且占用内存非常大，很短时间1G内存空闲就只剩下不到300M，而CPU使用率却很低。 找了个在线压力测试，并发30,进行3分钟压力访问，发现内存很快就所剩无几了，直到低于90M以后突然恢复到270M空闲时，发现MYSQL的进程被KILL了。压力测试结束后，内存并没有被释放。这就是问题所在了。 通过百度查询得知，PHP-CGI会释放内存，但并不会把内存归还系统，所以当过多的PHP-FPM子进程存在时，内存就会一点点被吃干，最终导致溢出。解决方法网上貌似很多，但看起来有点天书，选了一种比较好理解易操作的方法，就是修改php-fpm.conf文件，控制这个进程的数量。 找这个文件我就费了很大劲，网上的文章都不说这个文件在哪，对于小白来说，就有点吃力，最后找到，这个文件在php安装文件夹心下的etc文件夹里，如果是阿里云的话，应该就是 /alidata/server/php/etc里。 打开编辑这个文件，可以通过FTP或者LINUX命令行进行修改。主要涉及几个参数。 pm 这个是设置运行方式的，分别是static（静态）或者dynamic（动态） 默认应该是在214行左右，显示为 pm = dynamic，意思就是动态方式，如果内存小，比如512M，1G，2G之类，建议使用动态。 pm.max_children：静态方式下开启的php-fpm进程数量，这个是有在pm模式为static的情况下生效。 pm.start_servers：动态方式下的起始php-fpm进程数量，这个是pm位dynamic模式下需要设置的参数，意思就是启动运行时建立的起始php-fpm进程数量 大概在230行左右，我设置后的，pm.start_servers = 3 pm.min_spare_servers：动态方式下的最小php-fpm进程数 大概位置在235行，我设置后的，pm.min_spare_servers = 3 pm.max_spare_servers：动态方式下的最大php-fpm进程数量 大概位置在240行，我设置后的，pm.max_spare_servers = 10 还有一个就是pm.max_requests，这个在百度查询都的结果就是接受多少次请求后自动重启进程的，默认是500，不知道这个数值具体是指什么的，因为重启就意味着把php占用的空闲内存释放给系统，不过一旦这个值设置的过低，可能会导致所有的php-fpm进程在几乎同时重启，而重启过程中CPU占用率会飙升，且PHP会拒绝访问请求，所以这个值不能过低，按照我这个小白理解就是宁可适当的减少运行的子进程数，也不能过分的降低这个值。不知道对不对 大概位置在251行，我设置后的，pm.max_requests = 200 这就是我设置后的几个参数，保存后重启服务，再次观察，内存占用率基本稳定在400M，缓慢增长，经过了一晚的再次进行30并发的压力测试，虽然内存和CPU同样会在此时爆发增长，但是这个并发数还是挺住了，且在压力测试结束后，内存大部分被释放给系统了。最后又在wordpress安装了wp-super-cache缓存插件，很大程度降低了访问页面时对服务器的压力。 根据百度查到的，配置php-fpm并非由固定的模式，他基本是要找到一个平衡，对于我这样的小白来说，只能一点点的试，先改成这样运行一段时间观察下，后续再做调整，毕竟自己是小白，很多东西都得摸索，短时间内也无法确定效果，慢慢试吧。 linux命令行  top命令可以查看动态的系统资源占用情况，  ps aux可以查看当时占用系统资源的情况，非动态。 ------------------------- 回 252楼czfcyj的帖子 去看看171楼和172楼，感兴趣也可以看看我的发言 ------------------------- Re“零基础”系列课程如何在ECS上快递搭建一个WordPress站点 求助大神，我的数据库登陆不上去了，密码和用户名都对，显示#1045 错误 ------------------------- 回 247楼training的帖子 求助大神，我的数据库登陆不上去了，密码和用户名都对，显示#1045 错误

概述 当客户端访问目标服务器出现ping丢包或ping不通时，可以通过tracert或mtr等工具进行链路测试来判断问题根源。本文介绍如何通过工具进行链路测试和分析。 详细信息 阿里云提醒您： 如果您对实例或数据有修改、变更等风险操作，务必注意实例的容灾、容错能力，确保数据安全。 如果您对实例（包括但不限于ECS、RDS）等进行配置与数据修改，建议提前创建快照或开启RDS日志备份等功能。 如果您在阿里云平台授权或者提交过登录账号、密码等安全信息，建议您及时修改。 本文分别介绍如下链路测试方法。 链路测试工具 测试结果的简要分析 常见的链路异常场景 链路测试步骤 测试完成后的解决方法 链路测试工具 操作系统类型不同，链路测试所使用的工具也有所不同。简要介绍如下。 Linux系统 此处简单介绍两个链路测试工具。 工具一：mtr命令 mtr（My traceroute）几乎是所有Linux发行版本预装的网络测试工具。其将ping和traceroute的功能合并，所以功能更强大。mtr默认发送ICMP数据包进行链路探测。您也可以通过“-u”参数来指定使用UDP数据包进行探测。相对于traceroute只会做一次链路跟踪测试，mtr会对链路上的相关节点做持续探测并给出相应的统计信息。所以，mtr能避免节点波动对测试结果的影响，所以其测试结果更正确，建议优先使用。 用法说明 mtr [-BfhvrwctglxspQomniuT46] [--help] [--version] [--report] [--report-wide] [--report-cycles=COUNT] [--curses] [--gtk] [--csv|-C] [--raw] [--xml] [--split] [--mpls] [--no-dns] [--show-ips] [--address interface] [--filename=FILE|-F] [--ipinfo=item_no|-y item_no] [--aslookup|-z] [--psize=bytes/-s bytes] [--order fields] [--report-wide|-w] [--inet] [--inet6] [--max-ttl=NUM] [--first-ttl=NUM] [--bitpattern=NUM] [--tos=NUM] [--udp] [--tcp] [--port=PORT] [--timeout=SECONDS] [--interval=SECONDS] HOSTNAME 常见可选参数说明 --report：以报告模式显示输出。 --split：将每次追踪的结果分别列出来，而非统计整个结果。 --psize：指定ping数据包的大小。 --no-dns：不对IP地址做域名反解析。 --address：主机有多个IP地址时，设置发送数据包的IP地址。 -4：只使用IPv4协议。 -6：只使用IPv6协议。 另外，也可以在mtr运行过程中，输入类似如下的字母来快速切换模式。 ？或h：显示帮助菜单。 d：切换显示模式。 n：启用或禁用DNS域名解析。 u：切换使用ICMP或UDP数据包进行探测。 命令输出示例 返回结果说明 默认配置下，返回结果中各数据列的说明如下。 第一列（Host）：节点IP地址和域名。按 n 键可切换显示。 第二列（Loss%）：节点丢包率。 第三列（Snt）：每秒发送数据包数。默认值是10，可以通过“-c”参数指定。 第四列（Last）：最近一次的探测延迟。 第五、六、七列（Avg、Best、Worst）：分别是探测延迟的平均值、最小值和最大值。 第八列（StDev）：标准偏差。越大说明相应节点越不稳定。 工具二：traceroute命令 traceroute也是几乎所有Linux发行版本预装的网络测试工具，用于跟踪Internet协议（IP）数据包传送到目标地址时经过的路径。traceroute先发送小的具有最大存活时间值（Max_TTL）的UDP探测数据包，然后侦听从网关开始的整个链路上的ICMP TIME_EXCEEDED响应。探测从TTL=1开始，TTL值逐步增加，直至接收到ICMP PORT_UNREACHABLE消息。ICMP PORT_UNREACHABLE消息用于标识目标主机已经被定位，或命令已经达到允许跟踪的最大TTL值。traceroute默认发送UDP数据包进行链路探测。可以通过“-I”参数来指定使用ICMP数据包进行探测。 用法说明 traceroute [-I] [ -m Max_ttl ] [ -n ] [ -p Port ] [ -q Nqueries ] [ -r ] [ -s SRC_Addr ] [ -t TypeOfService ] [ -f flow ] [ -v ] [ -w WaitTime ] Host [ PacketSize ] 常见可选参数说明 -d：使用Socket层级的排错功能。 -f：设置第一个检测数据包的存活数值TTL的大小。 -F：设置不要分段标识。 -g：设置来源路由网关，最多可设置8个。 -i：主机有多个网卡时，使用指定的网卡发送数据包。 -I：使用ICMP数据包替代UDP数据包进行探测。 -m：设置检测数据包的最大存活数值TTL的大小。 -n：直接使用IP地址而非主机名称（禁用DNS反查）。 -p：设置UDP传输协议的通信端口。 -r：忽略普通的Routing Table，直接将数据包发送到目标主机上。 -s：设置本地主机发送数据包的IP地址。 -t：设置检测数据包的TOS数值。 -v：详细显示指令的执行过程。 -w：设置等待远端主机回包时间。 -x：开启或关闭数据包的正确性检验。 命令输出示例 Windows系统 此处简单介绍两个链路测试工具。 工具一：WinMTR（建议优先使用） WinMTR是mtr工具在Windows环境下的图形化实现，但进行了功能简化，只支持部分mtr的参数。WinMTR默认发送ICMP数据包进行探测，无法切换。和mtr一样，相比tracert，WinMTR能避免节点波动对测试结果的影响，所以测试结果更正确。所以在WinMTR可用的情况下，建议优先使用WinMTR进行链路测试。 用法说明 WinMTR无需安装，直接解压运行即可。操作方法非常简单，说明如下。 如下图所示，运行程序后，在 Host 字段输入目标服务器域名或IP，注意不要包含空格。 单击 Start 开始测试。开始测试后，相应按钮变成了 Stop。 运行一段时间后，单击 Stop 停止测试。 其它选项说明如下。 Copy Text to clipboard：将测试结果以文本格式复制到粘贴板。 Copy HTML to clipboard：将测试结果以HTML格式复制到粘贴板。 Export TEXT：将测试结果以文本格式导出到指定文件。 Export HTML：将测试结果以HTML格式导出到指定文件。 Options：可选参数，包括的可选参数如下。 Interval（sec）：每次探测的间隔（过期）时间。默认为1秒。 ping size(bytes)：ping探测所使用的数据包大小，默认为64字节。 Max hosts in LRU list：LRU列表支持的最大主机数，默认值为128。 Resolve names：通过反查IP地址，以域名显示相关节点。 返回结果说明 默认配置下，返回结果中各数据列的说明如下。 第一列（Hostname）：节点的IP或域名。 第二列（Nr）：节点编号。 第三列（Loss%）：节点丢包率。 第四列（Sent）：已发送的数据包数量。 第五列（Recv）：已成功接收的数据包数量。 第六、七、八、九列（Best 、Avg、Worst、Last）：分别是到相应节点延迟的最小值、平均值、最大值和最后一次值。 工具二：tracert命令行工具 tracert（Trace Route）是Windows自带的网络诊断命令行程序，用于跟踪Internet协议（IP）数据包传送到目标地址时经过的路径。 tracert通过向目标地址发送 ICMP 数据包来确定到目标地址的路由。在这些数据包中，tracert使用了不同的IP“生存期”，即TTL值。由于要求沿途的路由器在转发数据包前必须至少将TTL减少1，因此TTL实际上相当于一个跃点计数器（hop counter）。当某个数据包的TTL达到0时，相应节点就会向源计算机发送一个ICMP超时的消息。 tracert第一次发送TTL为1的数据包，并在每次后续传输时将TTL增加1，直到目标地址响应或达到TTL的最大值。中间路由器发送回来的ICMP超时消息中包含了相应节点的信息。 用法说明 tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] target_name 常见可选参数说明 -d：不要将地址解析为主机名（禁用DNS反解）。 -h：maximum_hops，指定搜索目标地址时的最大跃点数。 -j： host-list，指定沿主机列表的松散源路由。 -w：timeout，等待每个回复的超时时间（以毫秒为单位）。 -R：跟踪往返行程路径（仅适用于IPv6）。 -S：srcaddr，要使用的源地址（仅适用于IPv6）。 -4：强制使用IPv4。 -6：强制使用IPv6。 target_host：目标主机域名或IP地址。 命令输出示例 C:> tracert -d 223.5.5.5 通过最多 30 个跃点跟踪到 223.5.5.5 的路由 1 请求超时。 2 9 ms 3 ms 12 ms 192.168.X.X 3 4 ms 9 ms 2 ms X.X.X.X 4 9 ms 2 ms 1 ms XX.XX.XX.XX 5 11 ms 211.XX.X.XX 6 3 ms 2 ms 2 ms 2XX.XX.1XX.XX 7 2 ms 2 ms 1 ms 42.XX.2XX.1XX 8 32 ms 4 ms 3 ms 42.XX.2XX.2XX 9 请求超时。 10 3 ms 2 ms 2 ms 223.5.5.5 跟踪完成。 测试结果的简要分析 由于mtr（WinMTR）有更高的准确性，本文以其测试结果为例，参考如下要点进行分析。此处分析时以如下示例图为基础。 要点一：网络区域 正常情况下，从客户端到目标服务器的整个链路中会包含如下区域。 客户端本地网络，即本地局域网和本地网络提供商网络。如上图中的区域A。如果该区域出现异常，并且是客户端本地网络中的节点出现异常，则需要对本地网络进行相应的排查分析。如果是本地网络提供商网络出现异常，则需要向当地运营商反馈问题。 运营商骨干网络。如上图中的区域B。如果该区域出现异常，可以根据异常节点的IP查询其所属的运营商，直接向对应运营商进行反馈，或者通过阿里云技术支持，向运营商进行反馈。 目标服务器本地网络，即目标服务器所属提供商的网络。如上图中的区域C。如果该区域出现异常，需要向目标服务器所属的网络运营商反馈问题。 要点二：链路负载均衡 如上图中的区域D。如果中间链路某些部分启用了链路负载均衡，则mtr只会对首尾节点进行编号和探测统计。中间节点只会显示相应的IP或域名信息。 要点三：结合Avg（平均值）和StDev（标准偏差）综合判断 由于链路抖动或其它因素的影响，节点的Best和Worst值可能相差很大。Avg统计了自链路测试以来所有探测的平均值，所以能更好的反应出相应节点的网络质量。而StDev越高，则说明数据包在相应节点的延时值越不相同，即越离散。所以标准偏差值可用于协助判断Avg是否真实反应了相应节点的网络质量。例如，如果标准偏差很大，说明数据包的延迟是不确定的。可能某些数据包延迟很小，例如25ms，而另一些延迟却很大，例如350ms，但最终得到的平均延迟反而可能是正常的。所以，此时Avg并不能很好的反应出实际的网络质量情况。 综上，建议的分析标准如下。 如果StDev很高，则同步观察相应节点的Best和Worst，来判断相应节点是否存在异常。 如果StDev不高，则通过Avg来判断相应节点是否存在异常。 注：上述StDev高或者不高，并没有具体的时间范围标准。而需要根据同一节点其它列的延迟值大小来进行相对评估。比如，如果Avg为30ms，那么，当StDev为25ms，则认为是很高的偏差。而如果Avg为325ms，则StDev同样为25ms，反而认为是不高的偏差。 要点四：Loss%（丢包率）的判断 任一节点的Loss%（丢包率）如果不为零，则说明这一跳网络可能存在问题。导致相应节点丢包的原因通常有如下两种。 运营商基于安全或性能需求，限制了节点的ICMP发送速率，导致丢包。 节点确实存在异常，导致丢包。 结合异常节点及其后续节点的丢包情况，并参考如下内容，判定丢包原因。 如果随后节点均没有丢包，则通常表示异常节点丢包是由于运营商策略限制所致。可以忽略相关丢包。如上图中的第2跳所示。 如果随后节点也出现丢包，则通常说明异常节点确实存在网络异常，导致丢包。如上图中的第5跳所示。 另外，上述两种情况可能同时发生，即相应节点既存在策略限速，又存在网络异常。对于这种情况，如果异常节点及其后续节点连续出现丢包，而且各节点的丢包率不同，则通常以最后几跳的丢包率为准。如上图所示，在第 5、6、7跳均出现了丢包。所以，最终丢包情况，以第7跳的40%作为参考。 要点五：关于延迟 关于延迟，有如下两种场景。 场景一：延迟跳变 如果在某一跳之后延迟明显陡增，则通常判断该节点存在网络异常。如上图所示，从第5跳之后的后续节点延迟明显陡增，则推断是第5跳节点出现了网络异常。不过，高延迟并不一定完全意味着相应节点存在异常。如上图所示，第5跳之后，虽然后续节点延迟明显陡增，但测试数据最终仍然正常到达了目的主机。所以，延迟大也有可能是在数据回包链路中引发的。所以，需要结合反向链路测试一并分析。 场景二：ICMP限速导致延迟增加 ICMP策略限速也可能会导致相应节点的延迟陡增，但后续节点通常会恢复正常。如上图所示，第3跳有100%的丢包率，同时延迟也明显陡增。但随后节点的延迟马上恢复了正常。所以判断该节点的延迟陡增及丢包是由于策略限速所致。 常见的链路异常场景 常见的链路异常场景及测试报告如下。 场景一：目标主机网络配置不当 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. ??? 2. ??? 3. 1XX.X.X.X 0.0% 10 521.3 90.1 2.7 521.3 211.3 4. 11X.X.X.X 0.0% 10 2.9 4.7 1.6 10.6 3.9 5. 2X.X.X.X 80.0% 10 3.0 3.0 3.0 3.0 0.0 6. 2X.XX.XX.XX 0.0% 10 1.7 7.2 1.6 34.9 13.6 7. 1XX.1XX.XX.X 0.0% 10 5.2 5.2 5.1 5.2 0.0 8. 2XX.XX.XX.XX 0.0% 10 5.3 5.2 5.1 5.3 0.1 9. 173.194.200.105 100.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中，数据包在目标地址出现了100%的丢包。从数据上看是数据包没有到达，其实很有可能是目标服务器相关安全策略（比如防火墙、iptables 等）禁用了ICMP所致，导致目的主机无法发送任何应答。所以，该场景需要排查目标服务器的安全策略配置。 场景二：ICMP限速 示例数据如下。 [root@mycentos6 ~]# mtr --no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.X.XX 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 60.0% 10 27.2 25.3 23.1 26.4 2.9 6. 209.85.254.247 0.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 0.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 0.0% 10 39.6 40.5 39.5 46.7 2.2 在该示例中，在第5跳出现了明显的丢包，但后续节点均未见异常。所以推断是该节点ICMP限速所致。该场景对最终客户端到目标服务器的数据传输不会有影响，所以，分析的时候可以忽略。 场景三：环路 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.7X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.6X.X 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. 72.14.233.56 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. 72.14.233.57 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中，数据包在第5跳之后出现了循环跳转，导致最终无法到达目标服务器。这通常是由于运营商相关节点路由配置异常所致。所以，该场景需要联系相应节点归属运营商处理。 场景四：链路中断 示例数据如下。 [root@mycentos6 ~]# mtr —no-dns www.google.com My traceroute [v0.75] mycentos6.6 (0.0.0.0) Wed Jun 15 19:06:29 2016 Keys: Help Display mode Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 63.247.7X.X 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.6X.X 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 0.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 0.0% 10 6.7 6.8 6.7 6.9 0.1 5. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 6. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 7. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 8. ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 9 ??? 0.0% 10 0.0 0.0 0.0 0.0 0.0 在该示例中，数据包在第4跳之后就无法收到任何反馈。这通常是由于相应节点中断所致。建议结合反向链路测试做进一步确认。该场景需要联系相应节点归属运营商处理。 链路测试步骤 通常情况下，链路测试步骤如下图所示。 相关步骤的详情说明如下。 步骤一：获取本地网络对应的公网IP 在客户端本地网络内访问淘宝IP地址库，获取本地网络对应的公网IP地址。 步骤二：正向链路测试（ping和mtr） 从客户端向目标服务器做如下测试。 从客户端向目标服务器域名或IP做持续的ping测试，建议至少ping 100个数据包，记录测试结果。 根据客户端操作系统的不同，使用WinMTR或mtr，设置测试目的地址为目标服务器域名或IP，然后进行链路测试，记录测试结果。 步骤三：反向链路测试（ping和mtr） 进入目标服务器系统内部做如下测试。 从目标服务器向步骤一获取的客户端IP做持续的ping测试，建议至少ping 100个数据包，记录测试结果。 根据目标服务器操作系统的不同，使用WinMTR或mtr，设置测试目的地址为客户端的IP地址，然后进行链路测试，记录测试结果。 步骤四：测试结果分析 参阅测试结果的简要分析，对测试结果进行分析。确认异常节点后，访问如下链接或其他可以查询IP归属地的网站，获取该异常节点的归属运营商信息。如果是客户端本地网络相关节点出现异常，则需要对本地网络进行相应排查分析。如果是运营商相关节点出现异常，则需要向运营商反馈问题。查询结果类似如下。 测试完成后的解决方法 当出现ping丢包或ping不通时，首先请参考云服务器ECS网络故障诊断，排查是否为网络故障。 如果确认是因系统中病毒导致使用ping命令测试ECS实例的IP地址间歇性丢包，则可参考使用ping命令测试ECS实例的IP地址间歇性丢包进行处理。 如果是因删除ECS实例的默认安全组规则导致无法ping通ECS实例，可参考删除ECS实例的默认安全组规则导致无法ping通ECS实例进行处理。 如果在Linux系统内核没有禁PING的情况下，是因系统内部防火墙策略设置导致ECS服务器PING不通。可参考Linux系统的ECS中没有禁PING却PING不通的解决方法。