用 curl 测，测的是别的东西

一个不带浏览器标识到达的计数器请求，只写进一次记数访问通常会触及的十二处中的两处。它返回 200。它给出一张有效的计数器图片。没有任何地方说明另外十处被跳过了。

过滤器是干什么的，以及它让你付出什么

这里的计数器把机器人和人分开，分开的依据是客户端自称的标识。标记的名单很短，而且刻意做到没有歧义，curl/ 就在上面。空标识也在，理由是一个完全没有标识的请求不是浏览器。

这两点都没错。服务把一个光秃秃的 curl 当作机器人，并不冤枉它；它就是。问题在于，敲这条 curl 的人通常并不是在检查机器人识别是否管用。他们在检查计数是否管用 — 而他们悄悄点的是机器人那条路。

他们得到的是：当天的合计加一，机器人那一列加一，就这些。没有唯一访客的记录，所以关于访客一无所有。在线名单里没有条目。没有页面、没有国家、没有浏览器、没有操作系统、没有设备、没有小时。恰恰是任何人真正想检查的那些部分，就是没有跑到的部分。

这是值得停下来想一想的部分。一个什么都没测到的测试，通常会自己出声：一个错误、一个空结果、一个本该是数字的零。这里响应是 200。正文是一张真的计数器图片，3,361 字节。图片里的数字甚至还涨了，因为当天合计正是确实发生的两件事之一。

所以这个探针看起来是通过的。由它推出的一切 —「计数路径没问题」「新的列在写入」「这次改动没弄坏什么」— 都是从一次跳过了大半待测代码的运行里得出的结论。

这篇文章背后那次测量的第一版，请求的是 /c/<编号>。那不是计数器图片的地址；真正的地址带着样式和扩展名，/c/<编号>-<样式>.png。请求返回了 404。

脚本打印了三遍：写进 12 处中的 0 处。这是真的 — 而眯起眼睛看，它也恰好就是一个正常工作的机器人过滤器该有的样子。那个 404 就在同一张表里，在那些零的上一行。它有一分钟没被读到，因为零才是有意思的部分，而且它符合预期。

这和这篇文章讲的是同一个错误，只是高了一层：一次测量因为没人核对的原因给出了合情合理的答案。它被抓住，只是因为脚本去数十二张表里的行数，而不是相信那个请求 — 一个失败的请求和一个被过滤的请求，从外面看是一模一样的。

带上浏览器标识。一个参数，-A 加一串真实的标识，同一个请求就会写进十二处中的十处，而不是两处。

并且在另一头去数。响应码告诉你请求到达了；它不告诉你请求做了什么。凡是重点在副作用的地方 — 一个计数器、一个队列、一行日志、某处的一行记录 — 探针都必须去看那个副作用。在这里，对每一张相关的表做前后计数花了二十行代码，并且两次把含糊的结果变成了明确的：一次是因为过滤器，一次是因为那个 404。

即便带了浏览器标识，十二处中仍有两处是空的：机器人那一列，理应如此；以及来源列表，它没有记下发过去的来源。第二点这里不作解释，因为还没有去追查。写出来，是因为另一种做法是拿一张十一行的表，然后说它有十二行。