1. 概述
用户体验是网站和应用程序成功的关键因素之一，而错误页面作为用户与网站互动过程中不可避免的一部分。错误页面设计和实现对于提升整体用户体验具有重要意义。Nginx作为一款广泛使用的高性能Web服务器和反向代理服务器，为开发者提供了自定义错误页面的强大功能，使得网站管理员能够更好地控制用户在遇到错误时的体验。
1.1 Nginx错误页面简介
Nginx错误页面是在服务器遇到问题或无法正常处理用户请求时显示给用户的网页。这些错误通常以HTTP状态码的形式呈现，涵盖了多种不同类型的问题情况。为了更好地理解Nginx错误页面的范围和重要性，我们可以将常见的错误类型分类如下：
| 错误类型 | 状态码范围 | 常见示例 | 描述 |
| 客户端错误 | 4xx | 400（错误请求） 401（未授权） 403（禁止访问） 404（未找到） |
表示请求中存在问题，通常是由于用户输入错误或尝试访问未经授权的资源导致 |
| 服务器错误 | 5xx | 500（内部服务器错误） 502（错误网关） 503（服务不可用） 504（网关超时） |
表示服务器在处理请求时遇到了问题，可能是由于服务器配置错误、资源不足或后端服务故障等原因引起 |
| 重定向 | 3xx | 301（永久移动） 302（临时移动） 307（临时重定向） 308（永久重定向） |
虽然不是严格意义上的错误，但有时也需要自定义页面来提供更好的用户体验 |
默认情况下，Nginx会为这些错误提供一些基本的错误页面。这些默认页面通常包含错误代码和简短的描述信息，例如"404 Not Found"或"500 Internal Server Error"。然而，这些默认页面往往过于简单和技术化，可能会让普通用户感到困惑或沮丧。
自定义错误页面允许网站管理员为不同类型的错误创建更加友好、信息丰富且与网站风格一致的错误提示。通过精心设计的错误页面，可以向用户清晰地解释发生了什么问题，并提供可能的解决方案或替代操作。这不仅能够减少用户的挫折感，还能够维持品牌形象，甚至在某些情况下将潜在的负面体验转化为正面互动的机会。
例如，对于404错误，网站可以设计一个包含网站导航和搜索功能的自定义页面，帮助用户找到他们可能在寻找的内容。这个页面可以包括热门页面链接、网站地图或最近更新的内容列表，从而增加用户找到所需信息的机会。
对于503错误，网站可以创建一个说明系统维护状态和预计恢复时间的页面。这样的页面可以包含一个倒计时器，显示服务预计恢复的剩余时间，或者提供一个订阅功能，让用户在服务恢复时收到通知。这种方法可以有效减少用户的不确定性和焦虑。
对于401或403等安全相关的错误，自定义页面可以提供登录选项或解释如何获取必要的权限，而不是简单地显示"拒绝访问"的消息。这不仅能提高用户体验，还能减少对客户支持的需求。
通过利用Nginx的错误页面自定义功能，网站管理员可以针对不同类型的错误提供量身定制的用户体验。这种方法不仅可以显著提升网站的整体服务质量和用户满意度，还能够强化品牌形象，展示公司对用户体验的重视。在接下来的章节中，我们将深入探讨如何在Nginx中配置这些自定义错误页面，以及如何设计出既美观又实用的错误页面内容。
1.2 自定义错误页面的具体场景
自定义Nginx错误页面十分常用，在多种场景下都能发挥重要作用。
1、提高用户体验：当用户遇到404（页面未找到）错误时，精心设计的错误页面可以提供网站地图、搜索功能或推荐内容，帮助用户找到他们可能感兴趣的信息，而不是简单地显示"页面不存在"。
2、维护品牌一致性：自定义错误页面可以融入网站的整体设计风格，使用与主站相同的配色方案、字体和布局，确保即使在出错的情况下，用户仍然能感受到一致的品牌体验。
3、提供有用信息：对于503（服务暂时不可用）错误，自定义页面可以告知用户系统正在进行维护，并给出预计恢复时间，这比显示一个冷冰冰的"服务器错误"信息要有帮助得多。
4、安全考虑：在遇到401（未授权）或403（禁止访问）等安全相关错误时，自定义页面可以提供适当的解释，而不会泄露敏感的系统信息。
5、引导用户行为：例如，在遇到502（网关错误）时，错误页面可以鼓励用户稍后再试，或者提供联系客户支持的方式，从而减少用户流失。
6、收集反馈：自定义错误页面可以包含反馈表单，让用户报告他们遇到的具体问题，这对于网站管理员改进服务质量非常有价值。
7、国际化支持：对于面向全球用户的网站，自定义错误页面可以根据用户的语言偏好显示相应的本地化内容，提供更加亲和的用户体验。
通过合理利用Nginx的错误页面自定义功能，网站管理员可以将潜在的负面用户体验转化为展示品牌价值、提供帮助和维系用户关系的机会。这不仅能够提高用户满意度，还能够增强网站的专业形象，ultimately为提升整体用户留存率和网站声誉做出贡献。
在接下来的章节中，我们将深入探讨如何在Nginx中配置和优化自定义错误页面。
2. Nginx错误处理机制概述
Nginx作为一款高性能的Web服务器和反向代理服务器，具有强大而灵活的错误处理机制。这个机制不仅能够有效地处理服务器内部错误，还能为用户提供友好的错误提示，从而提升整体用户体验。
2.1 Nginx默认错误页面
Nginx作为一款功能强大的Web服务器，在处理各种HTTP请求时inevitably会遇到错误情况。为了确保用户在遇到这些错误时能够得到适当的反馈，Nginx提供了一套默认的错误页面机制。这些默认错误页面虽然简单，但能够有效地传达基本的错误信息。
默认情况下，Nginx的错误页面是由服务器自动生成的HTML内容。这些页面通常包含以下基本信息：
1、HTTP状态码：这是一个三位数的代码，用于表示请求的结果状态。例如，404表示"未找到"，500表示"内部服务器错误"。
2、错误描述：与状态码相对应的简短文字描述，如"Not Found"或"Internal Server Error"。
3、服务器信息：默认情况下，Nginx会在错误页面底部显示服务器名称和版本号。这个信息可以通过配置隐藏，以增强安全性。
Nginx的默认错误页面存储在服务器的文件系统中，通常位于/usr/share/nginx/html目录下。每个错误代码都有一个对应的HTML文件，例如404.html、500.html等。当发生错误时，Nginx会读取相应的文件并将其内容发送给客户端。
这些默认错误页面的HTML结构非常简单，通常只包含最基本的HTML标签和错误信息。例如，一个典型的404错误页面可能如下所示：
<html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.18.0</center> </body> </html>
虽然这些默认错误页面能够提供基本的错误信息，但它们存在几个明显的局限性：
1、缺乏个性化：默认错误页面对所有网站都是一样的，无法反映网站的品牌特性或设计风格。
2、信息有限：除了错误代码和简短描述外，默认页面没有提供任何额外的有用信息或指导。
3、用户体验欠佳：简陋的设计和有限的内容可能会让用户感到困惑或沮丧，特别是在遇到不常见的错误时。
4、缺乏交互性：默认页面没有提供任何帮助用户解决问题或继续浏览的选项。
5、潜在的安全风险：显示服务器版本信息可能会被攻击者利用来定位特定版本的漏洞。
尽管Nginx的默认错误页面提供了一种快速简单的方式来处理错误情况，但对于大多数生产环境的网站和应用来说，这些页面往往不够理想。为了提供更好的用户体验、维护品牌一致性并增强安全性，网站管理员通常会选择配置自定义错误页面。
自定义错误页面允许网站所有者创建与其网站设计相匹配的错误页面，提供更多有用的信息和导航选项，甚至包含交互式元素如搜索框或反馈表单。这不仅能够改善用户体验，还能够帮助用户在遇到错误时更容易地找到所需的信息或解决方案。
2.2 常见的HTTP错误状态码
在Web开发和服务器管理中，了解常见的HTTP错误状态码对于有效处理错误情况和提供良好的用户体验至关重要。HTTP状态码是服务器用来告知客户端请求处理结果的三位数字代码。虽然HTTP协议定义了多种状态码，但在实际应用中，某些错误状态码比其他的更为常见。以下是一个详细的表格，列出了最常见的HTTP错误状态码及其含义、可能的原因和建议的处理方法：
| 状态码 | 名称 | 描述 | 可能原因 | 建议处理方法 |
| 400 | 错误请求 | 服务器无法理解客户端的请求 | 请求语法错误、无效的请求消息帧、或欺骗性路由请求 | 检查并修正请求语法，确保请求格式正确 |
| 401 | 未授权 | 客户端请求未经授权 | 用户未登录或登录凭证无效 | 提供登录界面或引导用户重新认证 |
| 403 | 禁止访问 | 服务器拒绝执行请求 | 用户没有访问权限，或IP被封禁 | 检查用户权限，必要时提供申请权限的方法 |
| 404 | 未找到 | 请求的资源不存在 | 页面已被删除、URL拼写错误 | 提供网站地图、搜索功能或推荐内容 |
| 405 | 方法不允许 | 请求方法不被允许 | 使用了不支持的HTTP方法（如对只读资源使用POST） | 说明支持的请求方法，或引导用户使用正确的方法 |
| 408 | 请求超时 | 服务器等待客户端发送请求时超时 | 网络连接不稳定或客户端处理时间过长 | 建议用户检查网络连接并重试 |
| 500 | 内部服务器错误 | 服务器遇到了意外情况 | 服务器代码错误、配置问题 | 提供技术支持联系方式，并尽快修复服务器问题 |
| 502 | 错误网关 | 作为网关或代理的服务器从上游服务器收到无效响应 | 上游服务器故障或网络问题 | 检查上游服务器状态，建议用户稍后重试 |
| 503 | 服务不可用 | 服务器暂时无法处理请求 | 服务器过载或正在维护 | 说明服务器状态和预计恢复时间 |
| 504 | 网关超时 | 作为网关或代理的服务器未能及时从上游服务器获得响应 | 上游服务器响应慢或网络拥堵 | 检查上游服务器性能，建议用户稍后重试 |
这些常见的HTTP错误状态码涵盖了大多数用户可能遇到的问题情况。通过为这些错误提供清晰、有帮助的自定义错误页面，网站管理员可以显著改善用户体验，减少用户因遇到错误而产生的挫折感。
例如，对于404错误，可以设计一个包含网站导航、搜索功能和热门内容推荐的页面，帮助用户找到他们可能在寻找的信息。对于503错误，可以创建一个说明系统维护状态和预计恢复时间的页面，减少用户的不确定性。
此外，了解这些状态码的含义和可能原因，对于网站管理员和开发人员来说也是非常有价值的。它可以帮助他们更快地诊断和解决问题，提高网站的整体可靠性和用户满意度。
在配置Nginx的自定义错误页面时，可以针对这些常见的错误状态码设计专门的错误页面，以提供更加个性化和有帮助的用户体验。同时，也可以考虑为一些相似的错误（如所有的5xx服务器错误）使用同一个通用的错误页面模板，只是根据具体的错误代码动态调整页面内容。
3. 配置自定义错误页面
3.1 error_page指令介绍c
在Nginx配置中，error_page指令是实现自定义错误页面的核心。这个强大而灵活的指令允许管理员为不同的HTTP错误状态码指定自定义的错误处理方式。通过正确使用error_page指令，网站管理员
可以显著提升用户在遇到错误时的体验，同时保持网站的品牌一致性。
error_page指令的基本语法如下：
error_page code ... [=[response]] uri;
在这个语法中，各个部分的含义如下：
"code"代表一个或多个HTTP错误状态码。可以指定单个状态码，如404，也可以指定多个状态码，如500 502 503 504。
"response"是可选参数，用于更改响应状态码。如果不指定，则使用原始的错误状态码。
"uri"是在发生指定错误时Nginx应该返回的内容的位置。这可以是一个静态文件、一个命名位置或者一个URL。
error_page指令的工作原理是这样的：当Nginx遇到指定的错误状态码时，它会内部重定向到由"uri"参数指定的位置。这个重定向是在服务器内部完成的，客户端不会看到重定向过程。
以下是一些error_page指令使用的具体示例：
1、为404错误指定一个自定义错误页面：
error_page 404 /404.html;
这个配置告诉Nginx在遇到404错误时，返回/404.html页面的内容。
2、为多个错误使用同一个错误页面：
error_page 500 502 503 504 /50x.html;
这个配置将所有的5xx服务器错误都重定向到/50x.html页面。
3、更改响应状态码：
error_page 404 =200 /empty.gif;
这个配置在遇到404错误时，会返回/empty.gif文件的内容，但响应状态码会被更改为200。这种技术有时用于防止搜索引擎将404错误页面编入索引。
4、重定向到外部URL：
error_page 403 https://example.com/forbidden.html;
这个配置在遇到403错误时，会将用户重定向到一个外部URL。注意，这种情况下会发生实际的HTTP重定向，客户端会看到URL的变化。
5、使用命名位置：
location / { error_page 404 = @notfound; } location @notfound { proxy_pass http://backend; }
这个配置在遇到404错误时，会将请求代理到一个后端服务器。这种方法可以用于实现动态生成的错误页面。
error_page指令可以在Nginx配置的不同级别使用，包括http、server和location上下文。这提供了极大的灵活性，允许管理员在不同的配置层次上定制错误处理行为。
值得注意的是，error_page指令不仅限于处理错误情况。它还可以用于实现一些高级功能，如根据错误类型执行不同的操作、实现简单的A/B测试，甚至可以用作一种基本的URL重写机制。
然而，在使用error_page指令时也需要注意一些潜在的陷阱。例如，如果错误处理过程本身产生了错误，可能会导致循环重定向。为了避免这种情况，Nginx限制了内部重定向的次数，默认为10次。超过这个限制后，Nginx会返回最后一次重定向的结果。
3.2 基本配置示例c
在Nginx中配置自定义错误页面是一个相对简单的过程，但它可以显著提升网站的用户体验。本节将通过一系列基本配置示例，展示如何使用error_page指令来实现自定义错误页面。
首先，让我们从最简单的配置开始。假设我们想为404（未找到）错误设置一个自定义页面。我们可以在Nginx的服务器块中添加以下配置：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 /custom_404.html; location = /custom_404.html { internal; } }
在这个配置中，我们告诉Nginx当遇到404错误时，使用/custom_404.html页面。location块中的internal指令确保这个页面只能通过内部重定向访问，而不能直接从外部访问。
接下来，我们可以扩展这个配置，为多个常见错误设置自定义页面：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 /errors/404.html; error_page 500 502 503 504 /errors/50x.html; location ^~ /errors/ { internal; } }
在这个例子中，我们为404错误和所有的5xx错误设置了不同的错误页面。所有的错误页面都放在/errors/目录下，并且通过location指令和internal标记确保这些页面只能通过内部重定向访问。
有时，我们可能希望在错误发生时执行一些额外的操作。例如，对于某些错误，我们可能想记录更详细的日志。我们可以使用Nginx的post_action指令来实现这一点：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 = @notfound; location @notfound { return 404 /errors/404.html; post_action @404_logger; } location @404_logger { internal; proxy_pass http://localhost:8080/log404; } }
在这个配置中，当发生404错误时，Nginx不仅会显示自定义的404页面，还会向本地的一个日志服务发送请求，记录更详细的信息。
对于某些错误，我们可能希望改变返回的状态码。例如，有些网站管理员可能希望将404错误显示为
对于某些错误，我们可能希望改变返回的状态码。例如，有些网站管理员可能希望将404错误显示为200 OK，以防止搜索引擎将这些页面从索引中删除。虽然这种做法存在争议，但Nginx确实提供了这种可能性：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 =200 /errors/not_found.html; }
在这个配置中，当遇到404错误时，Nginx会返回/errors/not_found.html页面的内容，但状态码会被更改为200。
最后，让我们看一个更复杂的例子，它结合了多个技术：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 =200 /errors/404.php; error_page 500 502 503 504 /errors/50x.html; location ^~ /errors/ { internal; fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; fastcgi_index index.php; include fastcgi_params; } location @maintenance { return 503; } if (-f $document_root/maintenance.html) { return 503; } }
这个例子做了以下几件事：
1、对于404错误，它使用一个PHP脚本来生成错误页面，这允许我们创建动态的错误页面。
2、对于5xx错误，它使用静态的HTML页面。
3、它检查是否存在一个维护页面文件，如果存在，就返回503错误。
4、所有的错误页面都放在/errors/目录下，并且只允许通过内部重定向访问。
3.3 在不同上下文中使用error_pagec
Nginx的配置文件结构允许我们在不同的上下文中使用error_page指令，这为错误处理提供了极大的灵活性。主要的上下文包括http、server和location。每个上下文都有其特定的作用域，理解这些作用域对于正确配置错误页面至关重要。
在http上下文中使用error_page指令会为所有的虚拟主机设置一个全局的错误页面。这是最广泛的作用域，适用于需要为整个Nginx服务器设置统一错误处理的情况。例如：
http { error_page 404 /404.html; error_page 500 502 503 504 /50x.html; server { # 服务器配置 } server { # 另一个服务器配置 } }
在这个配置中，所有的虚拟主机都会使用相同的404和5xx错误页面，除非在server或location上下文中进行了覆盖。
server上下文允许我们为特定的虚拟主机配置错误页面。这比http上下文更具体，可以为不同的域名或IP地址设置不同的错误页面。例如：
server { listen 80; server_name example.com; error_page 404 /custom_404.html; error_page 500 502 503 504 /custom_50x.html; location / { # 位置配置 } }
在这个例子中，example.com域名会使用自定义的404和5xx错误页面，而其他虚拟主机则会使用http上下文中定义的默认错误页面（如果有的话）。
location上下文提供了最精细的控制，允许我们为特定的URL路径设置错误页面。这在需要为网站的不同部分提供不同的错误处理时非常有用。例如：
server { listen 80; server_name example.com; location / { error_page 404 /404.html; } location /api/ { error_page 404 /api_404.json; } }
在这个配置中，API请求（/api/路径下）的404错误会返回一个JSON格式的错误信息，而网站的其他部分则会显示一个HTML格式的404页面。
理解这些上下文的继承关系也很重要。较低级别的上下文（如location）会继承较高级别上下文（如server或http）的error_page设置，除非在较低级别上下文中明确覆盖。这允许我们在全局范围内设置默认的错误页面，同时为特定的虚拟主机或URL路径提供自定义的错误处理。
在实际应用中，我们可能会遇到需要在不同上下文中组合使用error_page指令的情况。例如：
http { error_page 500 502 503 504 /50x.html; server { listen 80; server_name example.com; error_page 404 /404.html; location /admin/ { error_page 403 /403_admin.html; } location /api/ { error_page 404 =200 /api/not_found.json; } } }
在这个复杂的例子中，我们在http上下文中为所有5xx错误设置了一个通用的错误页面。在server上下文中，我们为example.com域名定义了一个自定义的404错误页面。对于/admin/路径，我们设置了一个特殊的403错误页面。而对于/api/路径，我们不仅自定义了404错误的响应，还将状态码更改为200。
使用error_page指令时，还需要注意一些细节。例如，当指定的错误页面不存在时，Nginx会回退到默认的错误处理。此外，如果错误页面本身产生了错误，Nginx会尝试使用下一级的错误处理程序，直到达到内部重定向的最大次数（默认为10次）。
4. 高级错误页面配置
4.1 使用变量在错误页面中显示详细信息
在Nginx中配置自定义错误页面时，仅仅显示一个静态的错误信息往往是不够的。为了提供更有价值的错误反馈，我们可以利用Nginx提供的各种变量在错误页面中显示更详细的信息。这不仅能帮助用户更好地理解发生了什么错误，还能为网站管理员和开发人员提供有用的调试信息。
Nginx提供了大量的内置变量，这些变量包含了关于请求、响应和服务器状态的丰富信息。在错误页面中，我们可以使用这些变量来显示诸如请求的URL、客户端IP地址、服务器名称等信息。
要在错误页面中使用这些变量，我们需要先在Nginx配置中设置一些自定义的头部信息，然后在错误页面中读取这些头部。以下是一个基本的配置示例：
server { listen 80; server_name example.com; error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location / { add_header X-Error-Code $status; add_header X-Request-URI $request_uri; add_header X-Server-Name $server_name; } location = /404.html { internal; ssi on; set $error_code 404; set $error_message "Not Found"; } location = /50x.html { internal; ssi on; set $error_code $status; set $error_message "Server Error"; } }
在这个配置中，我们使用add_header指令添加了一些自定义的响应头。这些头部包含了错误代码、请求的URI和服务器名称。然后，我们为404和50x错误分别设置了专门的location块，并启用了服务器端包含（SSI）功能。
接下来，我们可以创建一个包含变量的错误页面模板。例如，对于404.html：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>404 Not Found</title> </head> <body> <h1>404 Not Found</h1> <p>很抱歉，您请求的页面不存在。</p> <p>错误代码：<!--#echo var="error_code" --></p> <p>请求的URL：<!--#echo var="http_x_request_uri" --></p> <p>服务器名称：<!--#echo var="http_x_server_name" --></p> </body> </html>
在这个HTML模板中，我们使用SSI指令来显示变量的值。注意，当通过SSI访问自定义头部时，我们需要在变量名前加上http_x_前缀。
通过这种方式，我们可以在错误页面中显示更多有用的信息。例如，我们可以添加以下变量：
$remote_addr：显示客户端的IP地址。
$http_user_agent：显示客户端的用户代理（浏览器信息）。
$http_referer：显示引荐页面的URL（如果有的话）。
$request_method：显示HTTP请求方法（GET、POST等）。
使用这些变量可以创建一个更加信息丰富的错误页面：
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title><!--#echo var="error_code" --> <!--#echo var="error_message" --></title> </head> <body> <h1><!--#echo var="error_code" --> <!--#echo var="error_message" --></h1> <p>很抱歉，在处理您的请求时发生了错误。</p> <h2>错误详情：</h2> <ul> <li>错误代码：<!--#echo var="error_code" --></li> <li>请求的URL：<!--#echo var="http_x_request_uri" --></li> <li>服务器名称：<!--#echo var="http_x_server_name" --></li> <li>客户端IP：<!--#echo var="remote_addr" --></li> <li>用户代理：<!--#echo var="http_user_agent" --></li> <li>引荐页面：<!--#echo var="http_referer" --></li> <li>请求方法：<!--#echo var="request_method" --></li> </ul> <p>如果问题持续存在，请联系网站管理员。</p> </body> </html>
这种方法不仅提供了更多的上下文信息，帮助用户理解错误的原因，还为网站管理员和开发人员提供了有价值的调试信息。然而，在使用这种方法时，我们需要注意几个重要的点：
首先，显示太多技术细节可能会让普通用户感到困惑或不安。因此，我们应该仔细考虑哪些信息对用户有帮助，哪些信息可能会引起不必要的担忧。
其次，某些信息可能涉及隐私或安全问题。例如，显示服务器的内部IP地址或详细的软件版本信息可能会被潜在的攻击者利用。因此，我们应该谨慎选择要显示的信息，并考虑对某些敏感信息进行模糊处理。
最后，使用服务器端包含（SSI）可能会对服务器性能产生一定影响，特别是在高流量的网站上。如果性能是一个关键考虑因素，我们可能需要考虑其他方法，如使用后端脚本动态生成错误页面。
在错误页面中使用变量来显示详细信息可以显著提升错误页面的信息价值和用户体验。通过合理使用这些变量，我们可以创建既对用户友好又对管理员有帮助的错误页面，从而更好地处理网站上的各种错误情况。
4.2 为多个错误代码设置同一个错误页面
在Nginx中，为多个错误代码设置同一个错误页面是一种常见且有效的做法。这种方法不仅可以简化配置，还能确保用户在遇到不同类型的错误时获得一致的体验。本节将详细探讨如何在Nginx中实现这一功能，以及这种做法的优势和注意事项。
首先，让我们看看如何在Nginx配置中为多个错误代码设置同一个错误页面。最基本的方法是使用error_page指令，并在其后列出所有需要处理的错误代码。例如：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 400 401 402 403 404 /4xx.html; error_page 500 501 502 503 504 /5xx.html; location = /4xx.html { internal; } location = /5xx.html { internal; } }
在这个配置中，我们将所有的4xx客户端错误都指向了/4xx.html页面，而所有的5xx服务器错误则指向了/5xx.html页面。internal指令确保这些错误页面只能通过内部重定向访问，而不能直接从外部访问。
这种配置方法的一个主要优势是简化了错误处理。不必为每种可能的错误都创建单独的页面，我们可以将相似的错误分组，并为每组提供一个通用的错误页面。这不仅减少了需要维护的文件数量，还确保了用户体验的一致性。
然而，使用同一个错误页面处理多个错误代码也带来了一个挑战：如何在错误页面中提供针对具体错误的信息？这个问题可以通过使用Nginx变量来解决。例如，我们可以在错误页面中使用$status变量来显示具体的错误代码：
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>错误 <!--#echo var="status" --></title> </head> <body> <h1>错误 <!--#echo var="status" --></h1> <p>很抱歉，在处理您的请求时发生了错误。</p> <p>错误代码：<!--#echo var="status" --></p> <p>请求的**URL**：<!--#echo var="request_uri" --></p> </body> </html>
这个HTML模板使用了服务器端包含（SSI）来显示动态内容。要使用SSI，我们需要在Nginx配置中启用它：
location = /4xx.html { internal; ssi on; } location = /5xx.html { internal; ssi on; }
通过这种方式，我们可以在一个通用的错误页面中显示特定于每个错误的信息。
为多个错误代码设置同一个错误页面还有一个重要的应用场景，那就是处理维护模式。当网站需要进行维护时，我们可能希望将所有请求都重定向到一个维护页面。这可以通过以下配置实现：
server { listen 80; server_name example.com; root /var/www/example.com; if (-f $document_root/maintenance.html) { return 503; } error_page 503 /maintenance.html; location = /maintenance.html { internal; } }
在这个配置中，如果maintenance.html文件存在，所有请求都会返回503错误，并显示维护页面。这提供了一种简单的方法来切换网站的维护模式。
尽管为多个错误代码设置同一个错误页面有很多优势，但我们也需要注意一些潜在的问题。首先，过于笼统的错误信息可能会让用户感到困惑。例如，对于404（未找到）和403（禁止访问）这样的错误，用户可能需要不同的指导。其次，某些错误可能需要特殊处理。例如，对于401（未授权）错误，我们可能希望提供登录选项而不是简单的错误信息。
为了解决这些问题，我们可以采用一种混合方法。对于大多数错误，我们使用通用的错误页面，但对于需要特殊处理的错误，我们提供专门的错误页面：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 400 402 403 404 /4xx.html; error_page 401 /401.html; error_page 500 501 502 503 504 /5xx.html; location = /4xx.html { internal; ssi on; } location = /401.html { internal; } location = /5xx.html { internal; ssi on; } }
这种配置为大多数4xx和5xx错误提供了通用的错误页面，但为401错误提供了一个专门的页面，可能包含登录表单或其他相关信息。
为多个错误代码设置同一个错误页面可以简化配置、减少维护工作，并为用户提供一致的体验。然而，在实施这种方法时，我们需要仔细考虑每种错误的特殊需求，并在通用性和特殊性之间找到适当的平衡。通过合理使用Nginx变量和条件配置，我们可以创建既简洁又灵活的错误处理系统，为用户提供清晰、有用的错误信息，同时也为网站管理员提供便利的维护工具。
4.3 错误页面重定向
在Nginx中，错误页面重定向是一种高级的错误处理技术，它允许我们将用户从一个错误页面引导到另一个页面或者完全不同的网站。这种方法在某些情况下非常有用，例如当我们想要将用户从一个不存在的页面重定向到网站的主页，或者将他们引导到一个专门的错误处理页面。
错误页面重定向可以通过Nginx的error_page指令结合return或rewrite指令来实现。这里有几种常见的实现方式：
首先，我们可以使用return指令进行简单的重定向。例如，如果我们想将所有的404错误重定向到网站的主页，可以这样配置：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 = @notfound; location @notfound { return 302 $scheme://$server_name/; } }
在这个配置中，当遇到404错误时，Nginx会将请求内部重定向到名为@notfound的位置块。在这个位置块中，我们使用return指令将用户重定向到网站的主页。302状态码表示这是一个临时重定向， 
变量代表当前的协议（ 
或 
），scheme变量代表当前的协议（HTTP或HTTPS），scheme变量代表当前的协议（HTTP或HTTPS），server_name变量代表服务器名称。
如果我们想要更灵活的重定向规则，可以使用rewrite指令。例如，我们可以将所有的404错误重定向到一个专门的"未找到"页面，同时保留原始的URL路径信息：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 = @notfound; location @notfound { rewrite ^(.*)$ /errors/404.php?path=$1 last; } }
在这个例子中，当遇到404错误时，Nginx会将请求重写到/errors/404.php页面，并将原始的URL路径作为查询参数传递。这允许我们在错误页面中显示用户原本试图访问的URL，或者基于这个信息提供更有针对性的建议。
有时，我们可能想要根据不同的错误代码执行不同的重定向。这可以通过多个error_page指令来实现：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 = @notfound; error_page 500 502 503 504 = @servererror; location @notfound { return 302 $scheme://$server_name/404.html; } location @servererror { return 302 $scheme://$server_name/50x.html; } }
在这个配置中，404错误会被重定向到/404.html，而所有的5xx错误都会被重定向到/50x.html。
重定向还可以用于实现更复杂的错误处理逻辑。例如，我们可以根据用户的语言偏好将他们重定向到不同的错误页面：
server { listen 80; server_name example.com; root /var/www/example.com; error_page 404 = @notfound; location @notfound { if ($http_accept_language ~* ^zh) { return 302 $scheme://$server_name/zh/404.html; } return 302 $scheme://$server_name/en/404.html; } }
这个配置会检查Accept-Language头部，如果用户的首选语言是中文，就重定向到中文的404页面，否则重定向到英文的404页面。
虽然错误页面重定向提供了很大的灵活性，但在使用时也需要注意一些潜在的问题：
首先，过多的重定向可能会影响网站的性能和用户体验。每次重定向都会增加页面加载时间，如果重定向链太长，可能会导致浏览器达到最大重定向次数限制。
其次，重定向可能会改变URL，这可能会让用户感到困惑，特别是当他们试图分享或书签标记一个页面时。在可能的情况下，最好使用内部重定向而不是外部重定向。
最后，重定向可能会影响搜索引擎优化（SEO）。搜索引擎可能会将频繁的重定向视为一种负面信号，特别是如果重定向导致了URL的显著变化。
运维系列.Nginx：自定义错误页面（二）:https://developer.aliyun.com/article/1582095
