网站“错误”与Google搜索之间的喜剧

 

不时会有人就 Search Console 中可能对网站显示的错误向我们提问，我们还不时会遇到似乎对错误来源感到困惑的用户。这都是可以理解的：访问网站时可能会出现许多问题，但所有问题无一例外都与一个用于实现访问的特定系统有关。在下面这个以简笔插图讲述的短故事中，我们将尝试阐明这些错误，这样或许会让它们看起来没那么可怕。让我们听故事吧！

开场白

我喜欢读书，所以在我小时候，当其他人梦想成为宇航员和消防员时，我梦想开一家图书馆。开在一座城堡里。但后来，我开始思考人们在来到我的新图书馆时和浏览书架上的图书时可能遇到的所有问题。您看，我的城堡位于很远的地方，我每年都会给城堡添点什么（比如“迎宾护城河”），这给当地制图员带来了问题。

第 1 章：DNS 错误

由于我们谈论的是一座城堡，它的位置有点模糊，很难找到。但不必担心：人们可以使用地图。但是，如果用的是没画上护城河的过时地图，或者地图太旧并且大部分文字已经被磨掉了，该怎么办？

这就是 DNS 错误（与普遍看法相反，与 Dungeons N Snakes 或 Dangerous Navigation System 无关）：您的顾客查询地图（DNS 服务器）但出于各种原因找不到位置。原因可能是地图上没有图书馆的位置（在 DNS 术语中称为 NXDOMAIN 错误），或者顾客难以辨认地图上的文字（在 DNS 术语中大致称为 FormErr）。

DNS 错误通常是由于 DNS 服务器上的某设置或缺少某设置而导致的。这意味着，除非您自行管理 DNS 服务器（为顾客绘制地图），否则必须与 DNS 提供商（或当地制图师）联系来修复错误。如果您不知道您的 DNS 提供商是谁，请尝试询问您的托管服务提供商或您注册域名处的联系人。

虽然顾客一方可能也有问题，例如，顾客忘记戴眼镜所以看不到地图上的文字；但问题更有可能在于地图本身。

第 2 章：网络连接错误

一旦勇敢的顾客知道通往城堡图书馆的路径，真正到达图书馆也堪称一场冒险之旅：在地下城中穿行，穿越食人鱼横行的护城河，有时还要对抗恶龙。

网络连接错误就像我们的顾客面对的障碍：客户端（浏览器、抓取工具等）与服务器之间的网络组件会拦截流量。这种拦截可能是意外的，例如主要路由器出现故障的情况；也可能是有意的，例如防火墙拦截流量的情况。

不幸的是，调试这种情况就像碰踢到脚趾一样令人不快：您需要确定从客户端到服务器的路由中哪个组件在进行拦截。很遗憾，路由中可能会有数十个独立组件，其中大多数既不由客户端也不由服务器管理，而且没有捷径可以发现是哪个组件阻碍了这个路径。但幸运的是，拦截通常是由紧挨着服务器或位于 CDN 末端的防火墙所致；如果您不擅于摆弄防火墙，那么与托管服务提供商或 CDN 联系是正确的选择。

第 3 章：服务器错误

不过，即使我们的顾客到达图书馆，图书馆本身也可能存在问题。例如，图书馆卡被水损坏，再也无法查找图书；或者更糟糕，顾客在前往图书馆的途中斗过的恶龙可能已经纵火烧了整个图书馆建筑。

这些基本上属于服务器错误：服务出了点问题，导致访问者无法获得要找的内容（图书）。如果您无法确定导致此问题的原因，请与您的服务器管理员或托管服务提供商联系。遗憾的是，客户端无法对其采取任何措施；顾客没法借阅图书，只能无功而返。

第 4 章：客户端错误

进入图书馆后，书迷顾客有时可能会要求借阅目前没法提供（因为已被另一读者借走）或被禁止借阅（因为小说被锁在禁区）的小说。这些属于客户端错误：客户端在某种意义上请求了错误的对象，但错误对象可能只是您的书架上当前没有的东西。

而有时，顾客想找的图书位于图书馆的禁区内，顾客需要满足某些条件（例如背出口令）才能进入禁区。

简而言之，所有客户端错误在技术上都要归责于待修复的客户端：您可以通过重定向网址（推荐备选图书）来帮助客户端，但大多数情况下客户端的请求无法实现。

尾声

只要结果是好的，便皆大欢喜：如果顾客可以克服所有这些困难进入图书馆，找到并借阅图书，他们最后便可以尽情阅读自己梦寐以求的精彩图书或是您的内容（如果您是网站所有者）。