著名的 啊，老年 web 开发者都知道的

你的脚本又不是 zabbix 的一部分，为什么要往 /var/log/zabbix 下写东西？

遇到过一次类似的，以后我配的对公服务 nginx 的默认 server context 都是直接返回 451

往好里想，ISO 那帮人搞了个不切实际的 OSI 网络七层模型，互联网圈子🐦都不🐦它一眼

@theklf4 我想说的意思是，一个由学生民间组织建起来的服务网站是某大学里所有单体网站流量最大的，只有网站群才超过它，这事本身就是意义，意义是真的有人用。
至于括号里那些，是为了注明我在这里用单体网站这个词所表示的网站范围，不是为了讨论谁比谁流量大奇怪不奇怪。你可以当这段不存在。

我校的镜像站是全校所有单体网站（也就是排除用于建立各单位新闻型门户网站的那个“网站群”建站系统）里流量最大的

对于完全不懂运维知识又要硬上生产环境的开发人员来说，大部分其它 web 开发语言写的系统到生产环境部署确实比 PHP 复杂。但是要上生产环境，运维知识是避不开的，不论是自己学还是别人学了跟你分工。

Kong 企业版会在国内直接面向企业用户销售或者通过做企业信息化实施的厂家集成销售吗？——来自一个用了好几年 Kong 开源版并且最近在评估 APISIX 的传统行业信息化人员

喜欢 Consolas 又要用非 Windows 系统可以试试开源仿制品 Inconsolata

还不是你们（我们）惯出来的毛病

另外，HTTP API 给 web 前端浏览器里用 JS 调用和给第三方应用系统的后端调用也是两种不同的场景，对最佳实践的选择也有影响。

如果发生错误，是与业务逻辑无关的系统错误（不论是客户端还是服务器，自己方还是外方），还是与系统无关的业务错误？前者表明系统没毛病，是用户操作的错，要由用户解决，并且允许出现的常态；后者表明用户操作没毛病，是系统的错，由技术人员（某方的开发或运维）来解决，即使发生的频率不低也不应该视为允许出现的常态。有些错误很容易分辨出属于哪一类，而有些就需要技术和业务都精通的老司机才能准确分辨。HTTP 状态码和 body 数据之争的本质是，针对这两类错误如何设计报错机制。

@iyaozhen 屁股决定脑袋。你所谓的对业务的监控，是指想知道业务挂了，这个问题本来就属于基建。我也说了，如果业务系统里发现有基建问题，硬生生抓住包成一个 200 抛回给调用方，这个我也不能接受的。但很多莱塞特福原教旨主义者想要做的是把业务逻辑层面的错误也给放到 HTTP 状态码里，比如一个大学生离校系统里要去查学生在各个单位的业务是否已结清，我一个图书馆系统的接口发现还有书没还的时候，给他返回 HTTP 200 再加一个 JSON 表示业务层面这个操作不成功，但我的系统没挂，调用方传进来的参数也符合 schema ，权限也对，所以在 HTTP 层面我认为没问题，不应该返回错误码……有人说这样不清真，应该改成在 HTTP 码里把这个当“错误”来返回，不能塞进 200 的 JSON 里。这不是扯鸡巴蛋吗。总不会有人为了方便监控离校系统调用图书馆系统接口时的业务逻辑错误率而想把我千奇百怪的业务错误码从 JSON 里提出来放到 HTTP 状态码吧。

当然，我坚决反对 JDBC 连不上数据库服务器的时候抓出来异常还要包到 200 里向上返回……业务逻辑上的错误（责任在甲乙方最终用户，不涉及基础设施运维）用 200 包起来返回是一个美丑的问题，基础设施错误还要这么搞，是沙雕还是沙壁的问题。

至于拿监控说事的……监控啥？

如果是为了监控基础设施，我 JSON 里封的是业务逻辑层面的错误，关你基础设施屁事？

如果是为了监控业务错误，却嫌错误代码封在 JSON 里不方便……你就是想让我把业务错误代码放到 HTTP 里去对吧？你是不是觉得我这边各种各样的业务错误怎么映射到 HTTP 那几个状态码里很简单？你个普罗米修斯崽懂个屁的业务。

我的业务 API 又不只是为了让你来做监控而存在的，我要给别的业务单位调用啊。HTTP 状态码没出错，业务状态码出错的时候，可以去找管业务系统的人处理，HTTP 状态码出错了找管基础设施的人处理，这两拨人不是同样技能的啊。业务端有个什么狗屁错（而且还不是那种 unrecoverable 的外部环境错，是业务逻辑的错，要业务用户处理的）都返回成 HTTP 错误码一级一级传上去，查个业务级错误都要基础设施的人联动，这是制造民怨吗？你来给我做基础设施架构让我有办法一键定位出错的层次和节点吗？可是我只能拿到够做业务功能的经费，而且是单个单个项目做，没有做基础设施的条件，我让一个行业人士起家的地方性行业性中小型业务信息化开发商给我做业务系统开发的时候顺便免费做一套云原生的微服务的可观测的可这个那个狗屁的基础设施，并且以后的其它同类业务开发商要逼着他们不允许用自己的积累，一定要做在这些所谓现代的平台上，这忒外祖母的现实吗？

@adoal 我这么说倒不是反对用 HTTP 状态码表示业务状态，而是说要想清楚以自己的团队和周边状态、项目背景、后续配套支持力度，甚至是组织机构设置、职权划分、撕逼流程，这样做是否真的能把事情做得更好，需要付出什么样的代价，做得更好的结果是否会引发其它可能的问题？工程上做选择都是 trade off ，有些看起来好的，能不能落地好是要结合实际的。

@jorneyr 你不是没说清楚，是没理解别人的答案。别人的意思大多都是让你换用支持 VPN 的路由器设备。不过这个事其实可大可小，往大里说可以问运营商卖 MPLS VPN 服务，这个可以做到全透明的，你自己的路由器都不用配置。不过看你表述，只是“可以购买路由器”，那应该不会花这种钱。网友们推荐的 WG 、ZT 之类的，看样子你们也未必有人能搞定技术门槛。那……关键词“蒲公英”可以看看。就是做向日葵远程控制的那个公司出的硬件。