本文旨在解决在使用 Nginx 配置自定义 400 错误页面时，通过 HTTP 访问 HTTPS 端口导致资源无法加载的问题。我们将分析问题原因，并提供配置 Nginx 以正确处理 HTTP 和 HTTPS 请求的方案，确保自定义错误页面能够正常显示，提升用户体验。通过配置默认服务器和调整 Nginx 配置，可以有效解决资源加载问题。
当使用 Nginx 配置自定义错误页面，特别是针对 SSL (HTTPS) 的站点时，可能会遇到一个常见问题：当用户尝试通过 HTTP 访问 HTTPS 端口时，虽然会显示自定义的 400 错误页面，但页面中的资源（如图片、CSS 样式等）无法正确加载。这通常是由于浏览器尝试通过错误的协议（HTTP）去请求资源，导致请求失败。
问题分析
Nginx 基于端口、协议（HTTP 或 HTTPS）和 server_name 来匹配请求。如果请求的协议与配置的 server block 不匹配，Nginx 可能无法找到合适的服务器块来处理请求，从而返回 400 错误。
具体到这个问题，当用户在浏览器中输入 http://192.168.1.1:789 时，浏览器发起的是 HTTP 请求，但 Nginx 配置中监听 789 端口的 server block 配置了 SSL，期望的是 HTTPS 请求。因此，Nginx 找不到匹配的 server block 来处理 HTTP 请求，虽然会显示自定义的 400 错误页面，但由于资源路径是基于 HTTP 的，导致资源加载失败。
解决方案：配置默认服务器
最推荐的解决方案是配置一个 default_server 来处理所有未匹配的 HTTP 请求。这可以确保所有进入服务器的请求都能被正确处理，即使它们不符合任何特定的 server block。
-
创建 HTTP 监听的 server block：
首先，需要创建一个监听 HTTP 端口（通常是 80）的 server block。这个 server block 将作为默认服务器，处理所有通过 HTTP 发起的请求。
server { listen 80 default_server; listen [::]:80 default_server; # IPv6 server_name _; # 匹配所有域名 # 返回 400 错误页面 error_page 400 /400_page.html; location = /400_page.html { root /etc/nginx/error_pages; internal; } # 其他错误页面配置（可选） error_page 404 /404_page.html; location = /404_page.html { root /etc/nginx/error_pages; internal; } # 重定向到 HTTPS (可选) return 301 https://$host$request_uri; }在这个配置中，listen 80 default_server; 指明这个 server block 是默认服务器，用于处理所有通过 80 端口发起的 HTTP 请求。server_name _; 表示匹配所有域名。return 301 https://$host$request_uri; (可选) 可以将所有 HTTP 请求重定向到 HTTPS。
-
修改 HTTPS 监听的 server block：
确保 HTTPS 监听的 server block 配置正确，并且包含必要的 SSL 证书信息。
upstream dashboardapp{ server test_server:80; } server { listen 789 ssl; server_name example.com; ssl_certificate /etc/nginx/certs/host.crt; ssl_certificate_key /etc/nginx/certs/host.key; location / { proxy_read_timeout 1800; proxy_connect_timeout 1800; proxy_send_timeout 1800; send_timeout 1800; proxy_hide_header x_destination; proxy_pass http://dashboardapp; } location /error_pages { root /etc/nginx/; } error_page 495 496 497 /400_page.html; location = /400_page.html { root /etc/nginx/error_pages; internal; } error_page 404 /404_page.html; location = /404_page.html { root /etc/nginx/error_pages; internal; } error_page 500 /500_page.html; location = /500_page.html { root /etc/nginx/error_pages; internal; } error_page 502 /502_page.html; location = /502_page.html { root /etc/nginx/error_pages; internal; } error_page 503 /503_page.html; location = /503_page.html { root /etc/nginx/error_pages; internal; } } -
资源路径问题：
确保自定义错误页面中的资源路径使用绝对路径或相对于网站根目录的路径。避免使用相对路径，因为浏览器可能会基于错误的 URL 来解析相对路径，导致资源加载失败。
例如，将 src="../error_pages/assets/images/img12.png" 修改为 src="/error_pages/assets/images/img12.png"，或者使用完整的 URL src="https://example.com/error_pages/assets/images/img12.png"。
-
重启 Nginx：
修改 Nginx 配置文件后，需要重启 Nginx 服务才能使配置生效。
sudo nginx -t # 检查配置是否正确 sudo systemctl restart nginx
替代方案：同一端口处理 HTTP 和 HTTPS（不推荐）
虽然不推荐，但技术上可以在同一端口上处理 HTTP 和 HTTPS 请求。这需要使用 Nginx 的 if 指令来判断请求的协议，并根据协议来处理请求。然而，这种方法可能会导致配置复杂，并且性能较低。
server {
listen 789;
server_name example.com;
if ($scheme = http) {
# 处理 HTTP 请求
return 301 https://$host$request_uri; # 重定向到 HTTPS
}
# 处理 HTTPS 请求
ssl_certificate /etc/nginx/certs/host.crt;
ssl_certificate_key /etc/nginx/certs/host.key;
location / {
proxy_read_timeout 1800;
proxy_connect_timeout 1800;
proxy_send_timeout 1800;
send_timeout 1800;
proxy_hide_header x_destination;
proxy_pass http://dashboardapp;
}
location /error_pages {
root /etc/nginx/;
}
error_page 495 496 497 /400_page.html;
location = /400_page.html {
root /etc/nginx/error_pages;
internal;
}
error_page 404 /404_page.html;
location = /404_page.html {
root /etc/nginx/error_pages;
internal;
}
error_page 500 /500_page.html;
location = /500_page.html {
root /etc/nginx/error_pages;
internal;
}
error_page 502 /502_page.html;
location = /502_page.html {
root /etc/nginx/error_pages;
internal;
}
error_page 503 /503_page.html;
location = /503_page.html {
root /etc/nginx/error_pages;
internal;
}
}总结
解决 Nginx 自定义 400 错误页面资源加载问题，关键在于正确处理 HTTP 和 HTTPS 请求。推荐的方法是配置一个 default_server 来处理所有未匹配的 HTTP 请求，并确保自定义错误页面中的资源路径使用绝对路径或相对于网站根目录的路径。避免在同一端口上同时处理 HTTP 和 HTTPS 请求，除非确实有必要，并充分了解其潜在的复杂性和性能影响。通过这些方法，可以确保自定义错误页面能够正常显示，提升用户体验。
