前一段时间，我突然接到运营的同事通报，沪江的一位老师在国外登录不上了沪江帐号。这本来是很普通的故障，但是在排查问题过程并不简单，我们意外获得了不少收获，在这里与大家分享。

　　我们首先判断，从故障现象来看，应该和后端无关，而是与前端有关，所以我们迅速查看了前端的日志，从日志来看，主要是用于判断客户端的地理位置接口持续出现错误，出现大量的HTTP Status Code 406(24小时之内出现了1w多条)。按照HTTP Status Code的规范，4开头的错误码和客户端有关，考虑到这个故障只出现在一位老师那里，初步判断406就是问题的根源。

　　随着掌握信息的增加，分析的加深，我们迅速解决了那位外教的故障，不幸的是，确认它和406没有关系。

　　但是，我们并不能就此打住。毕竟正常情况下响应的HTTP Status Code应该是200，那么大量的406到底是什么呢?为什么我们都无法复现?它们是如何引发的?如此大量的爆发应当引起用户的反馈了?为什么线上的反馈这么平静呢?

　　下图为日志平台中406错误的情况

　　排查过程

　　为了保障性能，我们的 Node 端并没有详细记录每个请求，所以单纯看406的日志并不能知道具体的原因。为了排查这个问题，我们紧急发布了在线补丁，具体记录每个请求的详细信息，然后在日志平台中看到了下面的请求

　　为了便于对比，我们在浏览器上截取了正常的请求。如下图

　　仔细对比这两个请求，结合错误码406的定义，我们的目光集中到了 Accept 这个header

　　日志中

　　而正常浏览器的行为

　　于是，我们在 Postman 中模拟了错误的请求，果然，我们复现了406错误，所以可以确认问题是 Accept 字段导致。

　　406 Not Acceptable 状态码表示客户端错误，表示请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。 译自HTTP协议规范RFC文档

　　我们上网查阅资料并也跟后端同事讨论了406的错误码，得知，如果请求头的 Accept 不符合事先约定的契约，就会返回406错误。报错的是 API 服务，返回的是 application/json 格式的数据， 然而请求中的 Accept 说明它并不支持这种格式，所以会报出406错误。

　　我们仔细检查了常见浏览器发送的请求，发现全部都包含 Accept: */* ;。看来，这些引发406的请求并不是普通用户发出来的。那么，究竟是谁发出了这些请求呢?

　　难道是CDN?

　　CDN 的全称是Content Delivery Network，即内容分发网络。 其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。 CDN 网络可以将服务器的内容缓存到分布全球的CDN节点，根据用户的访问 IP，就近连接 CDN，提高网站响应速度。(引用自google.com)

　　如今CDN已经是各种公司的普遍配置，沪江也不例外。我们仔细研究了引发406的请求来源IP，发现都是来自北京联通的少数节点。这样看来，CDN的嫌疑很大，大概有两种可能：1、原始请求头部的Accept 字段就是错的;2、原始请求头部的 Accept 字段是对的，但是在经过 CDN 节点的时候被 CDN 篡改了。由于以前遇到过 CDN 篡改头部的问题，我们初步判断是 CDN 的问题。

　　接下来，我们将北京联通的节点暂时回源，验证是不是 CDN 篡改了头部，同时也拿到了最终的用户 IP。 上网搜索这个IP详细的信息，上面赫然写着某搜索引擎的爬虫。原来，406并不是来自于普通用户，而是搜索引擎的爬虫。

　　花絮

　　在写文章的这几天，发现错误日志下降了很多，406错误都没有了。以为某某搜索引擎幡然悔悟，于是用当时出错的 IP 去日志平台搜索，发现该搜索引擎只是换了个策略。它的 Accept 字段做了修改，UA 头中加上了该搜索引擎特有的标识，摇身一变又成了正规的搜索引擎。

　　小结

　　对开发人员来说，当站点遇到大量的406错误的时候，不用太担心，好好查下日志，它很有可能是搜索引擎的爬虫导致的。