在 nginx 中处理 https 证书不受信任时的静态降级，核心思路是利用 `try_files` 指令的递归查找特性，结合自定义的错误页面或备用资源。当客户端请求一个不存在的文件或路径时，nginx 会尝试下一个文件；如果所有文件都不存在，则返回指定的错误码（如 404）。我们可以利用这一点，通过配置 `error_page` 指令捕获 ssl 握手失败或证书验证失败的特定状态，并将其重定向到一个静态 html 页面，该页面提供 http 访问入口或明确的错误提示。具体做法是：在 server 块中定义 `error_page 495 496 = /ssl_error.html;`，其中 495 和 496 是 nginx 内部用于表示 ssl 错误的代码，然后确保 `/ssl_error.html` 是一个实际存在的静态文件。
如何配置 Nginx 以捕获 SSL 证书错误并返回静态页面
要捕获 SSL 证书不受信任的错误，需要利用 Nginx 的内部错误码 495 (SSL Certificate Error) 和 496 (SSL No Valid Certificates)。这些错误发生在 TLS 握手阶段，早于 HTTP 请求的处理。因此，不能直接在 location 块中使用 try_files 来处理，而必须在 server 级别使用 error_page 指令。当客户端因证书问题断开连接时，Nginx 会生成这些内部错误码，并通过 error_page 将其映射到一个静态文件。这个静态文件可以是简单的 HTML，告知用户证书问题并提供 HTTP 链接（如果服务器也支持 HTTP）。
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/key.pem;
# 捕获 SSL 证书错误
error_page 495 496 =200 /ssl_error.html;
location / {
root /usr/share/nginx/html;
index index.html;
# 这里可以使用 try_files 处理其他静态资源
try_files $uri $uri/ /index.html;
}
# 确保静态错误页面存在
location = /ssl_error.html {
root /usr/share/nginx/html;
internal;
}
}
上述配置中，`error_page 495 496 =200 /ssl_error.html;` 是关键。它告诉 Nginx 当遇到证书错误时，不要返回默认的 400 或 500 错误，而是返回一个 200 OK 状态码，并加载 `/ssl_error.html` 文件。这个文件必须存在于 `root` 目录下。`internal` 指令确保该位置只能通过内部重定向访问，防止直接通过 URL 访问。这样，当用户浏览器显示“证书不受信任”警告并选择继续访问时，Nginx 实际上已经断开了连接，但如果是某些中间件或代理场景，可能需要更复杂的处理。对于纯 Nginx 静态服务，通常建议在 DNS 或负载均衡层处理证书问题，但在应用层，此方法可提供友好的降级体验。
如何通过 try_files 实现非 SSL 资源的静态降级
虽然 `try_files` 本身不直接处理 SSL 证书错误，但它可以在 HTTP 上下文中实现资源级别的降级。例如，当某个 HTTPS 资源不可用时，可以降级到 HTTP 版本或本地缓存。这通常用于混合内容或 CDN 回源场景。具体做法是：在 location 块中，先尝试获取 HTTPS 可用的资源，如果失败（通过 upstream 或 proxy），则 fallback 到本地静态文件。但这需要结合 `proxy_pass` 或 `alias` 使用，而非单纯的 `try_files`。更常见的用法是，在纯静态站点中，使用 `try_files` 来提供默认页面或 SPA 路由支持，这与 SSL 无关。然而，如果我们考虑的是在 SSL 终止后，对后端服务的降级，那么 `try_files` 可以用于在本地文件系统上查找备用资源。
server {
listen 80;
server_name example.com;
location /api/ {
# 尝试从上游获取，如果失败，则返回本地静态 JSON
proxy_pass http://backend_api;
# 注意：try_files 不能直接与 proxy_pass 混用
# 替代方案：使用 if 或 Lua 模块
}
# 更实用的静态降级示例：
location /static/ {
root /var/www/html;
# 如果请求的文件不存在，尝试另一个目录
try_files $uri $uri/ @fallback;
}
location @fallback {
root /var/www/fallback;
try_files $uri $uri/ /default.html;
}
}
在这个例子中，`try_files` 被用于在非 SSL 上下文中实现资源降级。当 `/static/` 下的文件不存在时，Nginx 会跳转到 `@fallback` 标签，在该标签中再次尝试从另一个目录查找。如果仍然找不到，则返回 `default.html`。这种模式可以用于 CDN 故障转移或本地缓存回退。虽然这不直接解决 SSL 证书问题，但它展示了 `try_files` 在静态资源管理中的强大能力。在实际生产中，建议将 SSL 处理和资源降级分离，前者由 Nginx 的 SSL 模块处理，后者由 `try_files` 或应用逻辑处理。
当 SSL 证书完全失效时，如何确保服务不中断
如果 SSL 证书完全失效（例如过期或被吊销），客户端将无法建立 TLS 连接，此时任何基于 HTTPS 的资源都无法访问。在这种情况下，`try_files` 无法发挥作用，因为连接尚未建立。唯一的解决方案是提供一个 HTTP 入口，或者使用自签名证书并引导用户手动信任。为了最小化中断，可以配置 Nginx 同时监听 HTTP 和 HTTPS，并在 HTTPS 失败时通过 DNS 或负载均衡器切换到 HTTP。此外，可以使用 `ssl_prefer_server_ciphers on;` 和强密码套件来提高兼容性，但这不能解决证书信任问题。最终，最可靠的降级策略是维护一个独立的 HTTP 服务，用于在 SSL 不可用时提供服务。
