我有一些 nginx 盒子用作我们的应用程序基础设施的反向代理,每个应用程序的正常配置基本上是:
geo $fooapp {
default fooapp;
}
upstream fooapp {
server ...
...
}
server {
listen 443;
...
location / {
proxy_pass https://$fooapp;
...
}
}
现在,当我们需要关闭应用程序进行维护时,我们有一个 maintenance.conf
当前只是简单定义:
upstream maintenance {
server 1.2.3.4:443;
}
其中 1.2.3.4 是一个简单的 HTTP 服务器,用于提供静态维护页面。有一些后台逻辑可以拉入状态消息,但它只会覆盖静态提供的纯 HTML 页面。
然后我们更新每个应用程序的 geo
块,例如:
geo $fooapp {
default maintenance;
10.0.0.0/16 fooapp;
...
}
这使我们的员工可以运行测试并在不公开的情况下对应用程序进行一般处理。
现在我们遇到的问题是,其中一些代理路由本身包含 API 端点,如果有人在我们打开维护模式之前打开了我们的一个应用程序,客户端代码仍将发出 API 请求。现在,这些 API 请求陷入全面维护,路由到 maintenance
上游,并获得带有 HTML 正文而不是他们期望的 JSON 的 200
响应。
我想做的是将 maintenance
上游提供的响应代码更改为 503。这将向浏览器/爬虫/等发送适当的信号,表明应用程序暂时不可用,并触发在客户端代码中正确处理错误。
我知道这绝对超出了 upstream
块配置的范围,所以我在考虑以下内容:
upstream maintenance_actual {
server 1.2.3.4:443;
}
server {
listen 127.0.0.1:8443;
location / {
override_status_code 503; #totally made up
proxy_pass https://maintenance_actual
}
}
upstream maintenance {
server 127.0.0.1:8443;
}
但我似乎找不到可以像这样修改响应代码的东西。
我并不特别倾向于将服务于维护页面的服务器上的配置更改为始终返回 503,因为这会掩盖该服务器本身是否有问题。