目录
客户端排查方式：
用 curl 命令时我们会关注什么
www.ruanyifeng.com/blog/2011/0…
curl -h
一、返回状态码
要注意状态码是否符合预期
要从5XX错误看出大概错误位置
比如 500 错误基本上可以肯定是web程序抛出了异常
502 错误基本可以确定是Nginx反向代理的web程序超时主动断开连接导致Nginx抛出 Bad Gateway
504 错误基本可以确定web程序处理时间超过nginx接受的最大等待时机抛出的 Gateway Time-out
关于502和504错误的区别 blog.csdn.net/dc_726/arti…
301 302 304 400 401 403 404 405 503等应该随时记得意义
二、了解这个请求通过的反向代理服务器
比如 curl -i www.youmi.net 可以看到
Server: marco/0.9
Via: xxxx
而其他的请求会看到其它的header，比如X-Via 之类的
如果不知道 Server 和 Via 的值的意义，可以Google一下那个值，很容易找到的。比如 marco/0.9 是又拍云的节点用的反向代理服务器，比如 Via: 1.1 varnish 是我们用于提高静态资源分发性能的 varnish 程序，比如Server是 Tengine的话，很有可能是没有CDN或者动态加速，直接连到负载均衡的。
另外还有一些CDN会在其它头部字段注明自己的身份，比如蓝汛会有个头部：
Powered-By-ChinaCache: HIT from CHN-GX-3-3WO
三、Content-Type， Content-Length
主要看静态文件的大小是否符合预期
四、缓存策略
包括 Expires， Cache-Control，Date 头部，要让CDN缓存静态文件的话Cache-Control头部需要设置为public。 stackoverflow.com/questions/3…
五、Connection
Connection 头一般会有两种情况，一种是 keep-alive， 另一种是 close。要在nginx配置 keepalive_timeout。它们使用场景不同，一般用上动态加速的，网页的请求一定要加上keep-alive。客户端API请求，比如夺宝的API接口没加动态加速，建议不要keep-alive，因为如果keep-alive会导致连接数过大，造成连不上的后果。
六、其它一些状态
CDN缓存是否命中，看MISS 和 HIT 关键字，某些CDN厂商特有的字段，比如X-Source: C/200 指的是节点从源拿到的HTTP Code 为200。
必须知道的curl使用方式
一、curl -i 或者 curl -I 查看头部
二、curl -H “Host:your.domain.com” “ http://1.2.3.4/index.html” 请求指定的服务器， 其中1.2.3.4 可能是测试服务器，也可能是CDN的某个节点，也可能是源服务器。
三、其它使用方式 curl -h
telnet ping
当发现网页打不开时，首先要做的就是ping一下那个网页的域名，看看能不能ping通，丢包率多少，延迟是否比平时高。需要对平时的ping值范围有准确的记忆，这里有比较特殊的ping值记录 conf.umlife.net/pages/viewp…
能ping通，还要确定服务器的端口是否开放，使用 telnet your.domain.com 80 来确认是否能够连上。
dig
dig 是个查看DNS和学习的神器, 可以通过它知道一个域名的CDN是怎样配置的，可以知道离下一次域名的DNS更新还有多久，以美团的DNS配置为例
首先通过 dig NS meituan.com 查看它用哪一家DNS服务提供商
稍微查查就知道是dnspod的付费 DNS 服务器。
打开美团的网页，可以看到它其中一个图片的域名是 p0.meituan.net, 再dig一下就可以知道它用了哪家服务，我们的请求到了哪个节点
然后可以通过查百度，或者查ccgslb.net的备案信息来查到美团的图片用了蓝汛的CDN（当然可能不全是，仅供参考）
还可以根据MX TXT记录查看一个域名的一些其它配置。
注意，dig的结果在世界各地可能是不一样的，假设研究一个域名的全球部署情况，可以登录到世界各地的服务器上dig一些那个域名的情况，看看得到的结果有什么变化。
问题排查例子，排查CDN节点配置是否正确，假设 dig p0.meituan.net 得到 IP 1.2.3.4， 我们需要查处1.2.3.4 的所在地，如果我们用的是广东电信，而1.2.3.4是上海移动，首先要看dig结果的最后
SERVER是否正确，如果是8.8.8.8 这些公共的DNS服务器一般不会是DNS服务器的问题，如果是我们自己搭的就要排查一下有没有特殊配置了。如果确定DNS SERVER没有问题，就可以直接找CDN厂商了。
如果我们用的是广东电信，1.2.3.4也是广东电信，则需要继续ping， telnet，curl 来测试那个URL。
使用网上提供的测试工具
查看各地的访问速度，连通性，CDN节点，DNS解析结果
服务端的排查方式：
当有不明原因造成服务不稳定时，首先应该看的是平时设置的相关监控点，对于网络问题，哪里报警就先看哪里，假设没有报警，首先应该看ganglia的图表。
看ganglia图表，分两种情况
一、单独一台机器出口（或者说是很少用到其它机器上的缓存和数据库的web服务器）
只要观察那台机器的出入流量就可以，对比一下某段时间的波动，是否存在入口流量不变出口流量巨变的情况，是否存在某个时间段流量巨变的情况，
这是主站服务器的流量情况，6号没波峰，而后面都有奇怪的波峰，但因为这个流量不大，很难留意到，不太了解业务状态的基础研发对这种问题很无解的，需要对接人经常留意并对这种波动的原因心中有数。
二、多台机器，多种服务协作的情况
比如gw，cache，db，balancer，可以想象，从gw往balancer发多少数据，balancer就收到多少数据，在机房网络内的数据交互是封闭的。当gw的入口流量变多了，原因不是balancer就是cache就是db给gw传的数据多了。比如这个月JCX的变化
可以通过查看balancer，cache，db的流量变化来确定究竟是哪一块的流量变小了，如果是balancer的流量变小，可能是业务下降了，如果是cache变少，可能是对缓存使用作了优化，其它同理。实事上那是云山对cache的使用做了优化，cache用量减少了一半。
还可以依靠cloudwatch这些工具监控网络流量和错误率，在海外的cloufront cloudwatch可以知道通过cloudfront的接口的错误率有多少，并告警。
假设服务器可能受到攻击，或者有一波不明真相的流量，或者服务器偶尔连不上，可以通过下面命令来排查
一、ifstat
观察当前的网速
二、iftop
观察什么IP请求得最厉害, 判断是不是有IP在攻击。iftop通俗易懂说明在 www.cnblogs.com/ggjucheng/a…
三、lsof 查看端口使用
比较常用的是 lsof -i:80 等查看哪个服务器端口连着指定的端口。
这里有个技巧：假设在一台缓存机器上排查什么进程用到SSDB可以在缓存机器上 lsof -i:8888 然后看到机器A的端口P在连，然后去到机器A，lsof -i:P 就可以知道是什么进程在连SSDB了。
lsof 的使用不止这些，详细一点请看文档和 www.cnblogs.com/peida/archi…
四、sysdig
五、syslog
对于一些看上去比较无解的，偶尔连不上，连接突然断开的情况，一定要tail一下syslog，很有可能会有conntrack full的提示，我们发生过好几次这样的事故 conf.umlife.net/pages/viewp… conf.umlife.net/pages/viewp…
六、conntrack
这个是主要给防火墙用的连接跟踪服务，如果太多连接的话连接数可能不够用，我们需要将最大连接数改大，将连接跟踪时间改小，一般我们会这样设置系统参数。以后会补充详细文档。
net.netfilter.nf_conntrack_max = 655350
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
七、nginx日志， nginx_status，查看计算rps
ngxtop, goaccess
