Nginx 配置
Nginx 的默认配置文件为
nginx.conf。
nginx -c xxx.conf- 以指定的文件作为配置文件，启动 Nginx。
配置文件实例
以下为一个 nginx.conf 配置文件实例：
基本规则
管理 Nginx 配置
随着 Nginx 配置的增长，您有必要组织、管理配置内容。
当您的 Nginx 配置增加时，组织配置的需求也会增加。 井井有条的代码是：
易于理解
易于维护
易于使用
使用
include指令可将常用服务器配置移动到单独的文件中，并将特定代码附加到全局配置，上下文等中。
我总是尝试在配置树的根目录中保留多个目录。 这些目录存储所有附加到主文件的配置文件。 我更喜欢以下结构：
html- 用于默认静态文件，例如 全局 5xx 错误页面
master- 用于主要配置，例如 ACL，侦听指令和域
_acls- 用于访问控制列表，例如 地理或地图模块
_basic- 用于速率限制规则，重定向映射或代理参数
_listen- 用于所有侦听指令； 还存储 SSL 配置
_server- 用于域（localhost）配置； 还存储所有后端定义
modules- 用于动态加载到 Nginx 中的模块
snippets- 用于 Nginx 别名，配置模板如果有必要，我会将其中一些附加到具有
server指令的文件中。
示例：
重加载 Nginx 配置
示例：
监听 80 和 443 端口
如果您使用完全相同的配置为 HTTP 和 HTTPS 提供服务（单个服务器同时处理 HTTP 和 HTTPS 请求），Nginx 足够智能，可以忽略通过端口 80 加载的 SSL 指令。
Nginx 的最佳实践是使用单独的服务器进行这样的重定向（不与您的主要配置的服务器共享），对所有内容进行硬编码，并且完全不使用正则表达式。
我不喜欢复制规则，但是单独的监听指令无疑可以帮助您维护和修改配置。
如果将多个域固定到一个 IP 地址，则很有用。 这使您可以将一个侦听指令（例如，如果将其保留在配置文件中）附加到多个域配置。
如果您使用的是 HTTPS，则可能还需要对域进行硬编码，因为您必须预先知道要提供的证书。
示例：
显示指定监听的地址和端口
Nginx 的 listen 指令用于监听指定的 IP 地址和端口号，配置形式为：listen <address>:<port>。若 IP 地址或端口缺失，Nginx 会以默认值来替换。
而且，仅当需要区分与 listen 指令中的同一级别匹配的服务器块时，才会评估 server_name 指令。
示例：
防止使用未定义的服务器名称处理请求
Nginx 应该阻止使用未定义的服务器名称（也使用 IP 地址）处理请求。它可以防止配置错误，例如流量转发到不正确的后端。通过创建默认虚拟虚拟主机可以轻松解决该问题，该虚拟虚拟主机可以捕获带有无法识别的主机标头的所有请求。
如果没有一个 listen 指令具有 default_server 参数，则具有 address：port 对的第一台服务器将是该对的默认服务器（这意味着 Nginx 始终具有默认服务器）。
如果有人使用 IP 地址而不是服务器名称发出请求，则主机请求标头字段将包含 IP 地址，并且可以使用 IP 地址作为服务器名称来处理请求。
在现代版本的 Nginx 中，不需要服务器名称_。如果找不到具有匹配的 listen 和 server_name 的服务器，Nginx 将使用默认服务器。如果您的配置分散在多个文件中，则评估顺序将不明确，因此您需要显式标记默认服务器。
Nginx 使用 Host 标头进行 server_name 匹配。它不使用 TLS SNI。这意味着对于 SSL 服务器，Nginx 必须能够接受 SSL 连接，这归结为具有证书/密钥。证书/密钥可以是任意值，例如自签名。
示例：
不要在 listen 或 upstream 中使用 hostname
通常，在 listen 或上游指令中使用主机名是一种不好的做法。
在最坏的情况下，Nginx 将无法绑定到所需的 TCP 套接字，这将完全阻止 Nginx 启动。
最好和更安全的方法是知道需要绑定的 IP 地址，并使用该地址代替主机名。 这也可以防止 Nginx 查找地址并消除对外部和内部解析器的依赖。
在 server_name 指令中使用$ hostname（计算机的主机名）变量也是不当行为的示例（类似于使用主机名标签）。
我认为也有必要设置 IP 地址和端口号对，以防止可能难以调试的软错误。
示例：
❌ 错误配置
⭕ 正确配置
指令中只配置一个 SSL
此规则使调试和维护更加容易。
请记住，无论 SSL 参数如何，您都可以在同一监听指令（IP 地址）上使用多个 SSL 证书。
我认为要在多个 HTTPS 服务器之间共享一个 IP 地址，您应该使用一个 SSL 配置（例如协议，密码，曲线）。这是为了防止错误和配置不匹配。
还请记住有关默认服务器的配置。这很重要，因为如果所有 listen 指令都没有 default_server 参数，则配置中的第一台服务器将是默认服务器。因此，您应该只使用一个 SSL 设置，并且在同一 IP 地址上使用多个名称。
从 Nginx 文档中：
这是由 SSL 协议行为引起的。在浏览器发送 HTTP 请求之前，已建立 SSL 连接，nginx 不知道所请求服务器的名称。因此，它可能仅提供默认服务器的证书。
还要看看这个：
TLS 服务器名称指示扩展名（SNI，RFC 6066）是在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案，它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个用于连接的证书。
另一个好主意是将常用服务器设置移到单独的文件（即 common / example.com.conf）中，然后将其包含在单独的服务器块中。
示例：
使用 geo/map 模块替代 allow/deny
使用地图或地理模块（其中之一）可以防止用户滥用您的服务器。这样就可以创建变量，其值取决于客户端 IP 地址。
由于仅在使用变量时才对其进行求值，因此甚至仅存在大量已声明的变量。地理位置变量不会为请求处理带来任何额外费用。
这些指令提供了阻止无效访问者的完美方法，例如使用 ngx_http_geoip_module。例如，geo 模块非常适合有条件地允许或拒绝 IP。
geo 模块（注意：不要将此模块误认为是 GeoIP）在加载配置时会构建内存基数树。这与路由中使用的数据结构相同，并且查找速度非常快。如果每个网络有许多唯一值，那么较长的加载时间是由在数组中搜索数据重复项引起的。否则，可能是由于插入基数树引起的。
我将两个模块都用于大型列表。您应该考虑一下，因为此规则要求使用多个 if 条件。我认为，对于简单的列表，毕竟允许/拒绝指令是更好的解决方案。看下面的例子：
示例：
Map 所有事物
使用地图管理大量重定向，并使用它们来自定义键/值对。
map 指令可映射字符串，因此可以表示例如 192.168.144.0/24 作为正则表达式，并继续使用 map 指令。
Map 模块提供了一种更优雅的解决方案，用于清晰地解析大量正则表达式，例如 用户代理，引荐来源。
您还可以对地图使用 include 指令，这样配置文件看起来会很漂亮。
示例：
为所有未匹配的路径设置根路径
为请求设置服务器指令内部的全局根路径。 它为未定义的位置指定根路径。
根据官方文档：
如果您在每个位置块中添加一个根路径，则不匹配的位置块将没有根路径。因此，重要的是，根指令必须在您的位置块之前发生，然后根目录指令可以在需要时覆盖该指令。
示例：
使用 return 指令进行 URL 重定向（301、302）
这是一个简单的规则。 您应该使用服务器块和 return 语句，因为它们比评估 RegEx 更快。
因为 Nginx 停止处理请求（而不必处理正则表达式），所以它更加简单快捷。
示例
配置日志轮换策略
日志文件为您提供有关服务器活动和性能以及可能出现的任何问题的反馈。 它们记录了有关请求和 Nginx 内部的详细信息。 不幸的是，日志使用了更多的磁盘空间。
您应该定义一个过程，该过程将定期存档当前日志文件并启动一个新日志文件，重命名并有选择地压缩当前日志文件，删除旧日志文件，并强制日志记录系统开始使用新日志文件。
我认为最好的工具是 logrotate。 如果我想自动管理日志，也想睡个好觉，那么我会在任何地方使用它。 这是一个旋转日志的简单程序，使用 crontab 可以工作。 它是计划的工作，而不是守护程序，因此无需重新加载其配置。
示例：
手动旋转
自动旋转
不要重复索引指令，只能在 http 块中使用
一次使用 index 指令。 它只需要在您的 http 上下文中发生，并将在下面继承。
我认为我们在复制相同规则时应格外小心。 但是，当然，规则的重复有时是可以的，或者不一定是大麻烦。
示例：
❌ 错误配置
⭕ 正确配置
Debugging
使用自定义日志格式
您可以在 Nginx 配置中作为变量访问的任何内容都可以记录，包括非标准的 HTTP 标头等。因此，这是一种针对特定情况创建自己的日志格式的简单方法。
这对于调试特定的
location指令非常有帮助。
示例：
使用调试模式来跟踪意外行为
通常，
error_log指令是在main中指定的，但是也可以在server或location块中指定，全局设置将被覆盖，并且这个error_log指令将设置其自己的日志文件路径和日志记录级别。如果要记录
ngx_http_rewrite_module(at the notice level) ，应该在http、server或location块中开启rewrite_log on;。注意：
永远不要将调试日志记录留在生产环境中的文件上
不要忘记在流量非常高的站点上恢复
error_log的调试级别必须使用日志回滚政策
示例：
将 debug 信息写入文件
将 debug 信息写入内存
IP 地址/范围的调试日志：
为不同服务器设置不同 Debug 配置
核心转储
核心转储基本上是程序崩溃时内存的快照。
Nginx 是一个非常稳定的守护程序，但是有时可能会发生正在运行的 Nginx 进程独特终止的情况。
如果要保存内存转储，它可以确保应启用两个重要的指令，但是，为了正确处理内存转储，需要做一些事情。 有关它的完整信息，请参见转储进程的内存（来自本手册）。
当您的 Nginx 实例收到意外错误或崩溃时，应始终启用核心转储。
示例：
性能
工作进程数
worker_processes- 用于设置 Nginx 的工作进程数。
worker_processes 的默认值为 1。
设置 worker_processes 的安全做法是将其设为 auto，则启动 Nginx 时会自动分配工作进程数。当然，也可以显示的设置一个工作进程数值。
一般一个进程足够了，你可以把连接数设得很大。（worker_processes: 1，worker_connections: 10,000）如果有 SSL、gzip 这些比较消耗 CPU 的工作，而且是多核 CPU 的话，可以设为和 CPU 的数量一样。或者要处理很多很多的小文件，而且文件总大小比内存大很多的时候，也可以把进程数增加，以充分利用 IO 带宽（主要似乎是 IO 操作有 block）
示例：
最大连接数
worker_connections- 单个 Nginx 工作进程允许同时建立的外部连接的数量。数字越大，能同时处理的连接越多。
worker_connections 不是随便设置的，而是与两个指标有重要关联：
内存
每个连接数分别对应一个 read_event、一个 write_event 事件，一个连接数大概占用 232 字节，2 个事件总占用 96 字节，那么一个连接总共占用 328 字节，通过数学公式可以算出 100000 个连接数大概会占用 31M = 100000 * 328 / 1024 / 1024，当然这只是 nginx 启动时，worker_connections 连接数所占用的 nginx。
操作系统级别”进程最大可打开文件数“。
进程最大可打开文件数受限于操作系统，可通过
ulimit -n命令查询，以前是 1024，现在是 65535。nginx 提供了 worker_rlimit_nofile 指令，这是除了 ulimit 的一种设置可用的描述符的方式。 该指令与使用 ulimit 对用户的设置是同样的效果。此指令的值将覆盖 ulimit 的值，如：worker_rlimit_nofile 20960; 设置 ulimits：ulimit -SHn 65535
使用 HTTP/2
HTTP / 2 将使我们的应用程序更快，更简单且更可靠。 HTTP / 2 的主要目标是通过启用完整的请求和响应多路复用来减少延迟，通过有效压缩 HTTP 标头字段来最小化协议开销，并增加对请求优先级和服务器推送的支持。
HTTP / 2 与 HTTP / 1.1 向后兼容，因此有可能完全忽略它，并且一切都会像以前一样继续工作，因为如果不支持 HTTP / 2 的客户端永远不会向服务器请求 HTTP / 2 通讯升级：它们之间的通讯将完全是 HTTP1 / 1。
请注意，HTTP / 2 在单个 TCP 连接中多路复用许多请求。 通常，当使用 HTTP / 2 时，将与服务器建立单个 TCP 连接。
您还应该包括 ssl 参数，这是必需的，因为浏览器不支持未经加密的 HTTP / 2。
HTTP / 2 对旧的和不安全的密码有一个非常大的黑名单，因此您应该避免使用它们。
示例：
维护 SSL 会话
客户端每次发出请求时都进行新的 SSL 握手的需求。默认情况下，内置会话缓存并不是最佳选择，因为它只能由一个工作进程使用，并且可能导致内存碎片，最好使用共享缓存。
使用
ssl_session_cache时，通过 SSL 保持连接的性能可能会大大提高。10M 的值是一个很好的起点（1MB 共享缓存可以容纳大约 4,000 个会话）。通过共享，所有工作进程之间共享一个缓存（可以在多个虚拟服务器中使用相同名称的缓存）。但是，大多数服务器不清除会话或票证密钥，因此增加了服务器受到损害将泄漏先前（和将来）连接中的数据的风险。
示例：
尽可能在 server_name 指令中使用确切名称
确切名称，以星号开头的通配符名称和以星号结尾的通配符名称存储在绑定到侦听端口的三个哈希表中。
首先搜索确切名称哈希表。 如果未找到名称，则搜索具有以星号开头的通配符名称的哈希表。 如果未在此处找到名称，则搜索带有通配符名称以星号结尾的哈希表。 搜索通配符名称哈希表比搜索精确名称哈希表要慢，因为名称是按域部分搜索的。
正则表达式是按顺序测试的，因此是最慢的方法，并且不可缩放。由于这些原因，最好在可能的地方使用确切的名称。
示例：
避免使用 if 检查 server_name
if 检查 server_name当 Nginx 收到请求时，无论请求的是哪个子域，无论是 www.example.com 还是普通的 example.com，如果始终对 if 指令进行评估。 由于您是在请求 Nginx 检查每个请求的 Host 标头。 效率极低。
而是使用两个服务器指令，如下面的示例。 这种方法降低了 Nginx 的处理要求。
示例：
❌ 错误配置
⭕ 正确配置
使用 $request_uri 来避免使用正则表达式
$request_uri 来避免使用正则表达式使用内置变量
$request_uri，我们可以完全避免进行任何捕获或匹配。默认情况下，正则表达式的代价较高，并且会降低性能。此规则用于解决将 URL 不变地传递到新主机，确保仅通过现有 URI 进行返回的效率更高。
示例：
❌ 错误配置
⭕ 正确配置
使用 try_files 指令确认文件是否存在
try_files 指令确认文件是否存在
try_filesis definitely a very useful thing. You can usetry_filesdirective to check a file exists in a specified order.
You should use
try_filesinstead ofifdirective. It's definitely better way than usingiffor this action becauseifdirective is extremely inefficient since it is evaluated every time for every request.
The advantage of using
try_filesis that the behavior switches immediately with one command. I think the code is more readable also.
try_filesallows you:
to check if the file exists from a predefined list
to check if the file exists from a specified directory
to use an internal redirect if none of the files are found
示例：
❌ 错误配置
⭕ 正确配置
使用 return 代替 rewrite 来做重定向
您应该使用服务器块和 return 语句，因为它们比通过位置块评估 RegEx 更简单，更快捷。 该指令停止处理，并将指定的代码返回给客户端。
示例：
❌ 错误配置
⭕ 正确配置
开启 PCRE JIT 来加速正则表达式处理
允许使用 JIT 的正则表达式来加速他们的处理。
通过与 PCRE 库编译 Nginx 的，你可以用你的 location 块进行复杂的操作和使用功能强大的 return 和 rewrite。
PCRE JIT 可以显著加快正则表达式的处理。 Nginx 的与 pcre_jit 比没有更快的幅度。
如果你试图在使用 pcre_jit;没有可用的 JIT，或者 Nginx 的与现有 JIT，但当前加载 PCRE 库编译不支持 JIT，将配置解析时发出警告。
当您编译使用 NGNIX 配置 PCRE 库时，才需要--with-PCRE-JIT 时（./configure --with-PCRE =）。当使用系统 PCRE 库 JIT 是否被支持依赖于库是如何被编译。
从 Nginx 的文档：
JIT 正在从与--enable-JIT 配置参数内置 8.20 版本开始 PCRE 库提供。当 PCRE 库与 nginx 的内置（--with-PCRE =）时，JIT 支持经由--with-PCRE-JIT 配置参数使能。
示例：
进行精确的位置匹配以加快选择过程
精确的位置匹配通常用于通过立即结束算法的执行来加快选择过程。
示例：
使用 limit_conn 改善对下载速度的限制
Nginx provides two directives to limiting download speed:
Nginx 提供了两个指令来限制下载速度：
limit_rate_after- 设置 limit_rate 指令生效之前传输的数据量
limit_rate- 允许您限制单个客户端连接的传输速率
此解决方案限制了每个连接的 Nginx 下载速度，因此，如果一个用户打开多个（例如） 视频文件，则可以下载
X * 连接到视频文件的次数。
示例：
Hardening
In this chapter I will talk about some of the Nginx hardening approaches and security standards.
🔰 始终保持Nginx为最新
基本原理
Nginx is a very secure and stable but vulnerabilities in the main binary itself do pop up from time to time. It's the main reason for keep Nginx up-to-date as hard as you can.
A very safe way to plan the update is once a new stable version is released but for me the most common way to handle Nginx updates is to wait a few weeks after the stable release.
Before update/upgrade Nginx remember about do it on the testing environment.
Most modern GNU/Linux distros will not push the latest version of Nginx into their default package lists so maybe you should consider install it from sources.
外部资源
🔰 以非特权用户身份运行
基本原理
仅更改进程所有者名称在安全性上没有真正的区别，另一方面，在安全性方面，最小特权原则规定，在给定系统中，不应向实体授予过多的权限以实现其目标，这样，只有主进程才能以root用户身份运行。
This is the default Nginx behaviour, but remember to check it.
例子
外部资源
🔰 禁用不必要的模块
基本原理
It is recommended to disable any modules which are not required as this will minimise the risk of any potential attacks by limiting the operations allowed by the web server.
The best way to unload unused modules is use the
configureoption during installation. If you have static linking a shared module you should re-compile Nginx.
Use only high quality modules and remember about that:
Unfortunately, many third‑party modules use blocking calls, and users (and sometimes even the developers of the modules) aren’t aware of the drawbacks. Blocking operations can ruin Nginx performance and must be avoided at all costs.
例子
外部资源
🔰 保护敏感资源
基本原理
Hidden directories and files should never be web accessible - sometimes critical data are published during application deploy. If you use control version system you should defninitely drop the access to the critical hidden directories like a
.gitor.svnto prevent expose source code of your application.
Sensitive resources contains items that abusers can use to fully recreate the source code used by the site and look for bugs, vulnerabilities, and exposed passwords.
例子
外部资源
🔰 隐藏Nginx版本号
基本原理
Disclosing the version of Nginx running can be undesirable, particularly in environments sensitive to information disclosure.
But the "Official Apache Documentation (Apache Core Features)" (yep, it's not a joke...) say:
Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety.
例子
外部资源
🔰 隐藏Nginx服务器签名
基本原理
One of the easiest first steps to undertake, is to prevent the web server from showing its used software via the server header. Certainly, there are several reasons why you would like to change the server header. It could be security, it could be redundant systems, load balancers etc.
In my opinion there is no real reason or need to show this much information about your server. It is easy to look up particular vulnerabilities once you know the version number.
You should compile Nginx from sources with
ngx_headers_moreto usedmore_set_headersdirective or use a nginx-remove-server-header.patch.
例子
外部资源
🔰 隐藏上游代理标头
基本原理
Securing a server goes far beyond not showing what's running but I think less is more is better.
When Nginx is used to proxy requests to an upstream server (such as a PHP-FPM instance), it can be beneficial to hide certain headers sent in the upstream response (e.g. the version of PHP running).
例子
外部资源
🔰 强制通过TLS进行所有连接
基本原理
TLS provides two main services. For one, it validates the identity of the server that the user is connecting to for the user. It also protects the transmission of sensitive information from the user to the server.
In my opinion you should always use HTTPS instead of HTTP to protect your website, even if it doesn’t handle sensitive communications. The application can have many sensitive places that should be protected.
Always put login page, registration forms, all subsequent authenticated pages, contact forms, and payment details forms in HTTPS to prevent injection and sniffing. Them must be accessed only over TLS to ensure your traffic is secure.
If page is available over TLS, it must be composed completely of content which is transmitted over TLS. Requesting subresources using the insecure HTTP protocol weakens the security of the entire page and HTTPS protocol. Modern browsers should blocked or report all active mixed content delivered via HTTP on pages by default.
Also remember to implement the HTTP Strict Transport Security (HSTS).
We have currently the first free and open CA - Let's Encrypt - so generating and implementing certificates has never been so easy. It was created to provide free and easy-to-use TLS and SSL certificates.
例子
force all traffic to use TLS:
force e.g. login page to use TLS:
外部资源
🔰 仅使用支持的最新OpenSSL版本
基本原理
Before start see Release Strategy Policies and Changelog on the OpenSSL website.
Criteria for choosing OpenSSL version can vary and it depends all on your use.
The latest versions of the major OpenSSL library are (may be changed):
the next version of OpenSSL will be 3.0.0
version 1.1.1 will be supported until 2023-09-11 (LTS)
last minor version: 1.1.1c (May 23, 2019)
version 1.1.0 will be supported until 2019-09-11
last minor version: 1.1.0k (May 28, 2018)
version 1.0.2 will be supported until 2019-12-31 (LTS)
last minor version: 1.0.2s (May 28, 2018)
any other versions are no longer supported
In my opinion the only safe way is based on the up-to-date and still supported version of the OpenSSL. And what's more, I recommend to hang on to the latest versions (e.g. 1.1.1).
If your system repositories do not have the newest OpenSSL, you can do the compilation process (see OpenSSL sub-section).
外部资源
🔰使用加密 2048位私钥
基本原理
Advisories recommend 2048 for now. Security experts are projecting that 2048 bits will be sufficient for commercial use until around the year 2030 (as per NIST).
The latest version of FIPS-186 also say the U.S. Federal Government generate (and use) digital signatures with 1024, 2048, or 3072 bit key lengths.
Generally there is no compelling reason to choose 4096 bit keys over 2048 provided you use sane expiration intervals.
If you want to get A+ with 100%s on SSL Lab (for Key Exchange) you should definitely use 4096 bit private keys. That's the main reason why you should use them.
Longer keys take more time to generate and require more CPU and power when used for encrypting and decrypting, also the SSL handshake at the start of each connection will be slower. It also has a small impact on the client side (e.g. browsers).
You can test above on your server with
openssl speed rsabut remember: in OpenSSL speed tests you see difference on block cipher speed, while in real life most cpu time is spent on asymmetric algorithms during ssl handshake. On the other hand, modern processors are capable of executing at least 1k of RSA 1024-bit signs per second on a single core, so this isn't usually an issue.
Use of alternative solution: ECC Certificate Signing Request (CSR) -
ECDSAcertificates contain anECCpublic key.ECCkeys are better thanRSA & DSAkeys in that theECCalgorithm is harder to break.
The "SSL/TLS Deployment Best Practices" book say:
The cryptographic handshake, which is used to establish secure connections, is an operation whose cost is highly influenced by private key size. Using a key that is too short is insecure, but using a key that is too long will result in "too much" security and slow operation. For most web sites, using RSA keys stronger than 2048 bits and ECDSA keys stronger than 256 bits is a waste of CPU power and might impair user experience. Similarly, there is little benefit to increasing the strength of the ephemeral key exchange beyond 2048 bits for DHE and 256 bits for ECDHE.
Konstantin Ryabitsev (Reddit):
Generally speaking, if we ever find ourselves in a world where 2048-bit keys are no longer good enough, it won't be because of improvements in brute-force capabilities of current computers, but because RSA will be made obsolete as a technology due to revolutionary computing advances. If that ever happens, 3072 or 4096 bits won't make much of a difference anyway. This is why anything above 2048 bits is generally regarded as a sort of feel-good hedging theatre.
My recommendation:
Use 2048-bit key instead of 4096-bit at this moment.
例子
For x25519:
➡️ ssllabs score: 100%
➡️ ssllabs score: 90%
外部资源
🔰 仅保留TLS 1.3和TLS 1.2
基本原理
It is recommended to run TLS 1.2/1.3 and fully disable SSLv2, SSLv3, TLS 1.0 and TLS 1.1 that have protocol weaknesses and uses older cipher suites (do not provide any modern ciper modes).
TLS 1.0 and TLS 1.1 must not be used (see Deprecating TLSv1.0 and TLSv1.1) and were superceded by TLS 1.2, which has now itself been superceded by TLS 1.3. They are also actively being deprecated in accordance with guidance from government agencies (e.g. NIST SP 80052r2) and industry consortia such as the Payment Card Industry Association (PCI) [PCI-TLS1].
TLS 1.2 and TLS 1.3 are both without security issues. Only these versions provides modern cryptographic algorithms. TLS 1.3 is a new TLS version that will power a faster and more secure web for the next few years. What's more, TLS 1.3 comes without a ton of stuff (was removed): renegotiation, compression, and many legacy algorithms:
DSA,RC4,SHA1,MD5,CBCMAC-then-Encrypt ciphers. TLS 1.0 and TLS 1.1 protocols will be removed from browsers at the beginning of 2020.
TLS 1.2 does require careful configuration to ensure obsolete cipher suites with identified vulnerabilities are not used in conjunction with it. TLS 1.3 removes the need to make these decisions. TLS 1.3 version also improves TLS 1.2 security, privace and performance issues.
Before enabling specific protocol version, you should check which ciphers are supported by the protocol. So if you turn on TLS 1.2 and TLS 1.3 both remember about the correct (and strong) ciphers to handle them. Otherwise, they will not be anyway works without supported ciphers (no TLS handshake will succeed).
I think the best way to deploy secure configuration is: enable TLS 1.2 without any
CBCCiphers (is safe enough) only TLS 1.3 is safer because of its handling improvement and the exclusion of everything that went obsolete since TLS 1.2 came up.
If you told Nginx to use TLS 1.3, it will use TLS 1.3 only where is available. Nginx supports TLS 1.3 since version 1.13.0 (released in April 2017), when built against OpenSSL 1.1.1 or more.
For TLS 1.3, think about using
ssl_early_datato allow TLS 1.3 0-RTT handshakes.
My recommendation:
Use only TLSv1.3 and TLSv1.2.
例子
TLS 1.3 + 1.2:
TLS 1.2:
➡️ ssllabs score: 100%
TLS 1.3 + 1.2 + 1.1:
TLS 1.2 + 1.1:
➡️ ssllabs score: 95%
外部资源
🔰 仅使用强密码
基本原理
This parameter changes quite often, the recommended configuration for today may be out of date tomorrow.
To check ciphers supported by OpenSSL on your server:
openssl ciphers -s -v,openssl ciphers -s -v ECDHEoropenssl ciphers -s -v DHE.
For more security use only strong and not vulnerable cipher suites. Place
ECDHEandDHEsuites at the top of your list. The order is important becauseECDHEsuites are faster, you want to use them whenever clients supports them. EphemeralDHE/ECDHEare recommended and support Perfect Forward Secrecy.
For backward compatibility software components you should use less restrictive ciphers. Not only that you have to enable at least one special
AES128cipher for HTTP/2 support regarding to RFC7540: TLS 1.2 Cipher Suites, you also have to allowprime256elliptic curves which reduces the score for key exchange by another 10% even if a secure server preferred order is set.
Also modern cipher suites (e.g. from Mozilla recommendations) suffers from compatibility troubles mainly because drops
SHA-1. But be careful if you want to use ciphers withHMAC-SHA-1- there's a perfectly good explanation why.
If you want to get A+ with 100%s on SSL Lab (for Cipher Strength) you should definitely disable
128-bitciphers. That's the main reason why you should not use them.
In my opinion
128-bitsymmetric encryption doesn’t less secure. Moreover, there are about 30% faster and still secure. For example TLS 1.3 useTLS_AES_128_GCM_SHA256 (0x1301)(for TLS-compliant applications).
It is not possible to control ciphers for TLS 1.3 without support from client to use new API for TLS 1.3 cipher suites. Nginx isn't able to influence that so at this moment it's always on (also if you disable potentially weak cipher from Nginx). On the other hand the ciphers in TLSv1.3 have been restricted to only a handful of completely secure ciphers by leading crypto experts.
For TLS 1.2 you should consider disable weak ciphers without forward secrecy like ciphers with
CBCalgorithm. Using them also reduces the final grade because they don't use ephemeral keys. In my opinion you should use ciphers withAEAD(TLS 1.3 supports only these suites) encryption because they don't have any known weaknesses.
Recently new vulnerabilities like Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL and Sleeping POODLE were published for websites that use
CBC(Cipher Block Chaining) block cipher modes. These vulnerabilities are applicable only if the server uses TLS 1.2 or TLS 1.1 or TLS 1.0 withCBCcipher modes. Look at Zombie POODLE, GOLDENDOODLE, & How TLSv1.3 Can Save Us All presentation from Black Hat Asia 2019.
Disable TLS cipher modes (all ciphers that start with
TLS_RSA_WITH_*) that use RSA encryption because they are vulnerable to ROBOT attack. Not all servers that support RSA key exchange are vulnerable, but it is recommended to disable RSA key exchange ciphers as it does not support forward secrecy.
You should also absolutely disable weak ciphers regardless of the TLS version do you use, like those with
DSS,DSA,DES/3DES,RC4,MD5,SHA1,null, anon in the name.
We have a nice online tool for testing compatibility cipher suites with user agents: CryptCheck. I think it will be very helpful for you.
My recommendation:
Use only TLSv1.3 and TLSv1.2 with below cipher suites:
例子
Cipher suites for TLS 1.3:
Cipher suites for TLS 1.2:
➡️ ssllabs score: 100%
Cipher suites for TLS 1.3:
Cipher suites for TLS 1.2:
Cipher suites for TLS 1.1 + 1.2:
➡️ ssllabs score: 90%
This will also give a baseline for comparison with Mozilla SSL Configuration Generator:
Modern profile with OpenSSL 1.1.0b (TLSv1.2)
Intermediate profile with OpenSSL 1.1.0b (TLSv1, TLSv1.1 and TLSv1.2)
外部资源
🔰 使用更安全的ECDH Curve
基本原理
In my opinion your main source of knowledge should be The SafeCurves web site. This site reports security assessments of various specific curves.
For a SSL server certificate, an "elliptic curve" certificate will be used only with digital signatures (
ECDSAalgorithm). Nginx provides directive to specifies a curve forECDHEciphers.
x25519is a more secure (also with SafeCurves requirements) but slightly less compatible option. I think to maximise interoperability with existing browsers and servers, stick toP-256 prime256v1andP-384 secp384r1curves. Of course there's tons of different opinions aboutP-256andP-384curves.
NSA Suite B says that NSA uses curves
P-256andP-384(in OpenSSL, they are designated as, respectively,prime256v1andsecp384r1). There is nothing wrong withP-521, except that it is, in practice, useless. Arguably,P-384is also useless, because the more efficientP-256curve already provides security that cannot be broken through accumulation of computing power.
Bernstein and Lange believe that the NIST curves are not optimal and there are better (more secure) curves that work just as fast, e.g.
x25519.
Keep an eye also on this:
Secure implementations of the standard curves are theoretically possible but very hard.
The SafeCurves say:
NIST P-224,NIST P-256andNIST P-384are UNSAFEFrom the curves described here only
x25519is a curve meets all SafeCurves requirements.
I think you can use
P-256to minimise trouble. If you feel that your manhood is threatened by using a 256-bit curve where a 384-bit curve is available, then useP-384: it will increases your computational and network costs.
If you use TLS 1.3 you should enable
prime256v1signature algorithm. Without this SSL Lab reportsTLS_AES_128_GCM_SHA256 (0x1301)signature as weak.
If you do not set
ssl_ecdh_curve, then Nginx will use its default settings, e.g. Chrome will preferx25519, but it is not recommended because you can not control default settings (seems to beP-256) from the Nginx.
Explicitly set
ssl_ecdh_curve X25519:prime256v1:secp521r1:secp384r1;decreases the Key Exchange SSL Labs rating.
Definitely do not use the
secp112r1,secp112r2,secp128r1,secp128r2,secp160k1,secp160r1,secp160r2,secp192k1curves. They have a too small size for security application according to NIST recommendation.
My recommendation:
Use only TLSv1.3 and TLSv1.2 and only strong ciphers with above curves:
例子
Curves for TLS 1.2:
➡️ ssllabs score: 100%
外部资源
🔰 使用强大的密钥交换和完善的前向保密性
基本原理
To use a signature based authentication you need some kind of DH exchange (fixed or ephemeral/temporary), to exchange the session key. If you use it, Nginx will use the default Ephemeral Diffie-Hellman (
DHE) paramaters to define how performs the Diffie-Hellman (DH) key-exchange. This uses a weak key (by default:1024 bit) that gets lower scores.
You should always use the Elliptic Curve Diffie Hellman Ephemeral (
ECDHE). Due to increasing concern about pervasive surveillance, key exchanges that provide Forward Secrecy are recommended, see for example RFC 7525.
For greater compatibility but still for security in key exchange, you should prefer the latter E (ephemeral) over the former E (EC). There is recommended configuration:
ECDHE>DHE(with min.2048 bitsize) >ECDH. With this if the initial handshake fails, another handshake will be initiated usingDHE.
DHEis slower thanECDHE. If you are concerned about performance, prioritizeECDHE-ECDSAoverDHE. OWASP estimates that the TLS handshake withDHEhinders the CPU by a factor of 2.4 compared toECDHE.
Diffie-Hellman requires some set-up parameters to begin with. Parameters from
ssl_dhparam(which are generated withopenssl dhparam ...) define how OpenSSL performs the Diffie-Hellman (DH) key-exchange. They include a field primepand a generatorg. The purpose of the availability to customize these parameter is to allow everyone to use own parameters for this. This can be used to prevent being affected from the Logjam attack.
Modern clients prefer
ECDHEinstead other variants and if your Nginx accepts this preference then the handshake will not use the DH param at all since it will not do aDHEkey exchange but anECDHEkey exchange. Thus, if no plainDH/DHEciphers are configured at your server but only Eliptic curve DH (e.g.ECDHE) then you don't need to set your ownssl_dhparamdirective. EnablingDHErequires us to take care of our DH primes (a.k.a.dhparams) and to trust inDHE.
Elliptic curve Diffie-Hellman is a modified Diffie-Hellman exchange which uses Elliptic curve cryptography instead of the traditional RSA-style large primes. So while I'm not sure what parameters it may need (if any), I don't think it needs the kind you're generating (
ECDHis based on curves, not primes, so I don't think the traditional DH params will do you any good).
Cipher suites using
DHEkey exchange in OpenSSL requiretmp_DHparameters, which thessl_dhparamdirective provides. The same is true forDH_anonkey exchange, but in practice nobody uses those. The OpenSSL wiki page for Diffie Hellman Parameters it says: To use perfect forward secrecy cipher suites, you must set up Diffie-Hellman parameters (on the server side). Look also at SSL_CTX_set_tmp_dh_callback.
If you use
ECDH/ECDHEkey exchange please see Use more secure ECDH Curve rule.
Default key size in OpenSSL is
1024 bits- it's vulnerable and breakable. For the best security configuration use your own DH Group (min.2048 bit) or use known safe ones pre-defined DH groups (it's recommended) from the Mozilla.
The
2048 bitis generally expected to be safe and is already very far into the "cannot break it zone". However years ago people expected 1024 bit to be safe so if you are after long term resistance You would go up to4096 bit(for both RSA keys and DH parameters). It's also important if you want to get 100% on Key Exchange of the SSL Labs test.
You should remember that the
4096 bitmodulus will make DH computations slower and won’t actually improve security.
There is good explanation about DH parameters recommended size:
Current recommendations from various bodies (including NIST) call for a
2048-bitmodulus for DH. Known DH-breaking algorithms would have a cost so ludicrously high that they could not be run to completion with known Earth-based technology. See this site for pointers on that subject.
You don't want to overdo the size because the computational usage cost rises relatively sharply with prime size (somewhere between quadratic and cubic, depending on some implementation details) but a
2048-bitDH ought to be fine (a basic low-end PC can do several hundreds of2048-bitDH per second).
Look also at this answer by Matt Palmer:
Indeed, characterising
2048 bitDH parameters as "weak as hell" is quite misleading. There are no known feasible cryptographic attacks against arbitrary strong 2048 bit DH groups. To protect against future disclosure of a session key due to breaking DH, sure, you want your DH parameters to be as long as is practical, but since1024 bitDH is only just getting feasible,2048 bitsshould be OK for most purposes for a while yet.
My recommendation:
If you use only TLS 1.3 -
ssl_dhparamis not required (not used). Also, if you useECDHE/ECDH-ssl_dhparamis not required (not used). If you useDHE/DH-ssl_dhparamwith DH parameters is required (min.2048 bit). By default no parameters are set, and thereforeDHEciphers will not be used.
例子
➡️ ssllabs score: 100%
➡️ ssllabs score: 90%
外部资源
🔰 防止零往返时间的重放攻击
基本原理
This rules is only important for TLS 1.3. By default enabling TLS 1.3 will not enable 0-RTT support. After all, you should be fully aware of all the potential exposure factors and related risks with the use of this option.
0-RTT Handshakes is part of the replacement of TLS Session Resumption and was inspired by the QUIC Protocol.
0-RTT creates a significant security risk. With 0-RTT, a threat actor can intercept an encrypted client message and resend it to the server, tricking the server into improperly extending trust to the threat actor and thus potentially granting the threat actor access to sensitive data.
On the other hand, including 0-RTT (Zero Round Trip Time Resumption) results in a significant increase in efficiency and connection times. TLS 1.3 has a faster handshake that completes in 1-RTT. Additionally, it has a particular session resumption mode where, under certain conditions, it is possible to send data to the server on the first flight (0-RTT).
For example, Cloudflare only supports 0-RTT for GET requests with no query parameters in an attempt to limit the attack surface. Moreover, in order to improve identify connection resumption attempts, they relay this information to the origin by adding an extra header to 0-RTT requests. This header uniquely identifies the request, so if one gets repeated, the origin will know it's a replay attack (the application needs to track values received from that and reject duplicates on non-idempotent endpoints).
To protect against such attacks at the application layer, the
$ssl_early_datavariable should be used. You'll also need to ensure that theEarly-Dataheader is passed to your application.$ssl_early_datareturns 1 if TLS 1.3 early data is used and the handshake is not complete.
However, as part of the upgrade, you should disable 0-RTT until you can audit your application for this class of vulnerability.
In order to send early-data, client and server must support PSK exchange mode (session cookies).
In addition, I would like to recommend this great discussion about TLS 1.3 and 0-RTT.
If you are unsure to enable 0-RTT, look what Cloudflare say about it:
Generally speaking, 0-RTT is safe for most web sites and applications. If your web application does strange things and you’re concerned about its replay safety, consider not using 0-RTT until you can be certain that there are no negative effects. [...] TLS 1.3 is a big step forward for web performance and security. By combining TLS 1.3 with 0-RTT, the performance gains are even more dramatic.
例子
Test 0-RTT with OpenSSL:
Enable 0-RTT with $ssl_early_data variable:
外部资源
🔰 防御BEAST攻击
基本原理
Generally the BEAST attack relies on a weakness in the way
CBCmode is used in SSL/TLS.
More specifically, to successfully perform the BEAST attack, there are some conditions which needs to be met:
vulnerable version of SSL must be used using a block cipher (
CBCin particular)JavaScript or a Java applet injection - should be in the same origin of the web site
data sniffing of the network connection must be possible
To prevent possible use BEAST attacks you should enable server-side protection, which causes the server ciphers should be preferred over the client ciphers, and completely excluded TLS 1.0 from your protocol stack.
例子
外部资源
🔰 缓解CRIME / BREACH攻击
基本原理
Disable HTTP compression or compress only zero sensitive content.
You should probably never use TLS compression. Some user agents (at least Chrome) will disable it anyways. Disabling SSL/TLS compression stops the attack very effectively. A deployment of HTTP/2 over TLS 1.2 must disable TLS compression (please see RFC 7540: 9.2. Use of TLS Features).
CRIME exploits SSL/TLS compression which is disabled since nginx 1.3.2. BREACH exploits HTTP compression
Some attacks are possible (e.g. the real BREACH attack is a complicated) because of gzip (HTTP compression not TLS compression) being enabled on SSL requests. In most cases, the best action is to simply disable gzip for SSL.
Compression is not the only requirement for the attack to be done so using it does not mean that the attack will succeed. Generally you should consider whether having an accidental performance drop on HTTPS sites is better than HTTPS sites being accidentally vulnerable.
You shouldn't use HTTP compression on private responses when using TLS.
I would gonna to prioritise security over performance but compression can be (I think) okay to HTTP compress publicly available static content like css or js and HTML content with zero sensitive info (like an "About Us" page).
Remember: by default, Nginx doesn't compress image files using its per-request gzip module.
Gzip static module is better, for 2 reasons:
you don't have to gzip for each request
you can use a higher gzip level
You should put the
gzip_static on;inside the blocks that configure static files, but if you’re only running one site, it’s safe to just put it in the http block.
例子
外部资源
🔰 HTTP严格传输安全性
基本原理
Generally HSTS is a way for websites to tell browsers that the connection should only ever be encrypted. This prevents MITM attacks, downgrade attacks, sending plain text cookies and session ids.
The header indicates for how long a browser should unconditionally refuse to take part in unsecured HTTP connection for a specific domain.
When a browser knows that a domain has enabled HSTS, it does two things:
always uses an
https://connection, even when clicking on anhttp://link or after typing a domain into the location bar without specifying a protocolremoves the ability for users to click through warnings about invalid certificates
I recommend to set the
max-ageto a big value like31536000(12 months) or63072000(24 months).
There are a few simple best practices for HSTS (from The Importance of a Proper HTTP Strict Transport Security Implementation on Your Web Server):
The strongest protection is to ensure that all requested resources use only TLS with a well-formed HSTS header. Qualys recommends providing an HSTS header on all HTTPS resources in the target domain
It is advisable to assign the max-age directive’s value to be greater than
10368000seconds (120 days) and ideally to31536000(one year). Websites should aim to ramp up the max-age value to ensure heightened security for a long duration for the current domain and/or subdomainsRFC 6797, section 14.4 advocates that a web application must aim to add the
includeSubDomaindirective in the policy definition whenever possible. The directive’s presence ensures the HSTS policy is applied to the domain of the issuing host and all of its subdomains, e.g.example.comandwww.example.comThe application should never send an HSTS header over a plaintext HTTP header, as doing so makes the connection vulnerable to SSL stripping attacks
It is not recommended to provide an HSTS policy via the http-equiv attribute of a meta tag. According to HSTS RFC 6797, user agents don’t heed
http-equiv="Strict-Transport-Security"attribute on<meta>elements on the received content`
To meet the HSTS preload list standard a root domain needs to return a
strict-transport-securityheader that includes both theincludeSubDomainsandpreloaddirectives and has a minimummax-ageof one year. Your site must also serve a valid SSL certificate on the root domain and all subdomains, as well as redirect all HTTP requests to HTTPS on the same host.
You had better be pretty sure that your website is indeed all HTTPS before you turn this on because HSTS adds complexity to your rollback strategy. Google recommend enabling HSTS this way:
Roll out your HTTPS pages without HSTS first
Start sending HSTS headers with a short
max-age. Monitor your traffic both from users and other clients, and also dependents' performance, such as adsSlowly increase the HSTS
max-ageIf HSTS doesn't affect your users and search engines negatively, you can, if you wish, ask your site to be added to the HSTS preload list used by most major browsers
例子
➡️ ssllabs score: A+
外部资源
🔰 降低XSS风险（内容安全策略）
基本原理
CSP reduce the risk and impact of XSS attacks in modern browsers.
Whitelisting known-good resource origins, refusing to execute potentially dangerous inline scripts, and banning the use of eval are all effective mechanisms for mitigating cross-site scripting attacks.
The inclusion of CSP policies significantly impedes successful XSS attacks, UI Redressing (Clickjacking), malicious use of frames or CSS injections.
CSP is a good defence-in-depth measure to make exploitation of an accidental lapse in that less likely.
The default policy that starts building a header is: block everything. By modifying the CSP value, the programmer loosens restrictions for specific groups of resources (e.g. separately for scripts, images, etc.).
Before enable this header you should discuss with developers about it. They probably going to have to update your application to remove any inline script and style, and make some additional modifications there.
Strict policies will significantly increase security, and higher code quality will reduce the overall number of errors. CSP can never replace secure code - new restrictions help reduce the effects of attacks (such as XSS), but they are not mechanisms to prevent them!
You should always validate CSP before implement: CSP Evaluator and Content Security Policy (CSP) Validator.
For generate a policy: https://report-uri.com/home/generate. Remember, however, that these types of tools may become outdated or have errors.
例子
外部资源
🔰 控制Referer标头（Referrer-Policy）的行为
基本原理
Determine what information is sent along with the requests.
例子
外部资源
🔰 提供点击劫持保护（X-Frame-Options）
基本原理
Helps to protect your visitors against clickjacking attacks. It is recommended that you use the
x-frame-optionsheader on pages which should not be allowed to render a page in a frame.
例子
外部资源
🔰 防止某些类型的XSS攻击（X-XSS-Protection）
基本原理
Enable the cross-site scripting (XSS) filter built into modern web browsers.
例子
外部资源
🔰 防止Sniff Mimetype中间件（X-Content-Type-Options）
基本原理
It prevents the browser from doing MIME-type sniffing (prevents "mime" based attacks).
例子
外部资源
🔰 拒绝使用浏览器功能（功能策略）
基本原理
This header protects your site from third parties using APIs that have security and privacy implications, and also from your own team adding outdated APIs or poorly optimised images.
例子
外部资源
🔰 拒绝不安全的HTTP方法
基本原理
Set of methods support by a resource. An ordinary web server supports the
HEAD,GETandPOSTmethods to retrieve static and dynamic content. Other (e.g.OPTIONS,TRACE) methods should not be supported on public web servers, as they increase the attack surface.
例子
外部资源
🔰 防止缓存敏感数据
基本原理
This policy should be implemented by the application architect, however, I know from experience that this does not always happen.
Don' to cache or persist sensitive data. As browsers have different default behaviour for caching HTTPS content, pages containing sensitive information should include a
Cache-Controlheader to ensure that the contents are not cached.
One option is to add anticaching headers to relevant HTTP/1.1 and HTTP/2 responses, e.g.
Cache-Control: no-cache, no-storeandExpires: 0.
To cover various browser implementations the full set of headers to prevent content being cached should be:
Cache-Control: no-cache, no-store, private, must-revalidate, max-age=0, no-transform>Pragma: no-cache>Expires: 0
例子
外部资源
🔰 控制缓冲区溢出攻击
基本原理
Buffer overflow attacks are made possible by writing data to a buffer and exceeding that buffers’ boundary and overwriting memory fragments of a process. To prevent this in Nginx we can set buffer size limitations for all clients.
例子
外部资源
🔰 缓解慢速HTTP DoS攻击（关闭慢速连接）
基本原理
Close connections that are writing data too infrequently, which can represent an attempt to keep connections open as long as possible.
You can close connections that are writing data too infrequently, which can represent an attempt to keep connections open as long as possible (thus reducing the server’s ability to accept new connections).
例子
外部资源
反向代理
使用与后端协议兼容的 pass 指令
All
proxy_*directives are related to the backends that use the specific backend protocol.
You should use
proxy_passonly for HTTP servers working on the backend layer (set also thehttp://protocol before referencing the HTTP backend) and other*_passdirectives only for non-HTTP backend servers (like a uWSGI or FastCGI).
Directives such as
uwsgi_pass,fastcgi_pass, orscgi_passare designed specifically for non-HTTP apps and you should use them instead of theproxy_pass(non-HTTP talking).
For example:
uwsgi_passuses an uwsgi protocol.proxy_passuses normal HTTP to talking with uWSGI server. uWSGI docs claims that uwsgi protocol is better, faster and can benefit from all of uWSGI special features. You can send to uWSGI information what type of data you are sending and what uWSGI plugin should be invoked to generate response. With http (proxy_pass) you won't get that.
示例：
❌ 错误配置
⭕ 正确配置
小心 proxy_pass 指令中的斜杠
proxy_pass 指令中的斜杠注意尾随斜杠，因为 Nginx 会逐字替换部分，并且您可能会得到一些奇怪的 URL。
如果 proxy_pass 不带 URI 使用（即 server:port 之后没有路径），Nginx 会将原始请求中的 URI 与所有双斜杠
../完全一样。
proxy_pass中的 URI 就像别名指令一样，意味着 Nginx 将用proxy_pass指令中的 URI 替换与位置前缀匹配的部分（我故意将其与位置前缀相同），因此 URI 将与请求的相同，但被规范化（没有小写斜杠和其他所有内容） 员工）。
示例：
仅使用 $host 变量设置和传递 Host 头
几乎应该始终将
$host用作传入的主机变量，因为无论用户代理如何行为，它都是保证具有某种意义的唯一变量，除非您特别需要其他变量之一的语义。变量
$host是请求行或http头中的主机名。 变量$server_name是我们当前所在的服务器块的名称。
区别：
$host包含“按此优先顺序：请求行中的主机名，或“主机”请求标头字段中的主机名，或与请求匹配的服务器名”如果请求中包含HTTP主机标头字段，则
$http_host包含该内容（始终等于HTTP_HOST请求标头）
$server_namecontains theserver_nameof the virtual host which processed the request, as it was defined in the Nginx configuration. If a server contains multiple server names, only the first one will be present in this variable
http_host, moreover, is better than$host:$server_portbecause it uses the port as present in the URL, unlike$server_portwhich uses the port that Nginx listens on.
示例：
正确设置 X-Forwarded-For 头的值
X-Forwarded-For 头的值基本原理
In the light of the latest httpoxy vulnerabilities, there is really a need for a full example, how to use
HTTP_X_FORWARDED_FORproperly. In short, the load balancer sets the 'most recent' part of the header. In my opinion, for security reasons, the proxy servers must be specified by the administrator manually.
X-Forwarded-Foris the custom HTTP header that carries along the original IP address of a client so the app at the other end knows what it is. Otherwise it would only see the proxy IP address, and that makes some apps angry.
The
X-Forwarded-Fordepends on the proxy server, which should actually pass the IP address of the client connecting to it. Where a connection passes through a chain of proxy servers,X-Forwarded-Forcan give a comma-separated list of IP addresses with the first being the furthest downstream (that is, the user). Because of this, servers behind proxy servers need to know which of them are trustworthy.
The proxy used can set this header to anything it wants to, and therefore you can't trust its value. Most proxies do set the correct value though. This header is mostly used by caching proxies, and in those cases you're in control of the proxy and can thus verify that is gives you the correct information. In all other cases its value should be considered untrustworthy.
Some systems also use
X-Forwarded-Forto enforce access control. A good number of applications rely on knowing the actual IP address of a client to help prevent fraud and enable access.
Value of the
X-Forwarded-Forheader field can be set at the client's side - this can also be termed asX-Forwarded-Forspoofing. However, when the web request is made via a proxy server, the proxy server modifies theX-Forwarded-Forfield by appending the IP address of the client (user). This will result in 2 comma separated IP addresses in theX-Forwarded-Forfield.
A reverse proxy is not source IP address transparent. This is a pain when you need the client source IP address to be correct in the logs of the backend servers. I think the best solution of this problem is configure the load balancer to add/modify an
X-Forwarded-Forheader with the source IP of the client and forward it to the backend in the correct form.
Unfortunately, on the proxy side we are not able to solve this problem (all solutions can be spoofable), it is important that this header is correctly interpreted by application servers. Doing so ensures that the apps or downstream services have accurate information on which to make their decisions, including those regarding access and authorization.
There is also an interesing idea what to do in this situation:
To prevent this we must distrust that header by default and follow the IP address breadcrumbs backwards from our server. First we need to make sure the
REMOTE_ADDRis someone we trust to have appended a proper value to the end ofX-Forwarded-For. If so then we need to make sure we trust theX-Forwarded-ForIP to have appended the proper IP before it, so on and so forth. Until, finally we get to an IP we don’t trust and at that point we have to assume that’s the IP of our user. - it comes from Proxies & IP Spoofing by Xiao Yu.
例子
外部资源
不要在反向代理后面使用带有 $scheme 的 X-Forwarded-Proto
$scheme 的 X-Forwarded-Proto反向代理可以设置
X-Forwarded-Proto，以告知应用程序它是HTTPS还是HTTP甚至是无效名称。schema 变量仅在需要的时候才会被评估（仅用于当前请求）。如果设置了 $schema 变量且沿途遇上多个代理，则会导致变形。例如：如果客户端转到https://example.com，则代理将方案值存储为HTTPS。 如果代理与下一级代理之间的通信是通过HTTP进行的，则后端会将方案视为HTTP。
示例：
始终将 Host，X-Real-IP 和 X-Forwarded 标头传递给后端
基本原理
When using Nginx as a reverse proxy you may want to pass through some information of the remote client to your backend web server. I think it's good practices because gives you more control of forwarded headers.
It's very important for servers behind proxy because it allow to interpret the client correctly. Proxies are the "eyes" of such servers, they should not allow a curved perception of reality. If not all requests are passed through a proxy, as a result, requests received directly from clients may contain e.g. inaccurate IP addresses in headers.
X-Forwardedheaders are also important for statistics or filtering. Other example could be access control rules on your app, because without these headers filtering mechanism may not working properly.
If you use a front-end service like Apache or whatever else as the front-end to your APIs, you will need these headers to understand what IP or hostname was used to connect to the API.
Forwarding these headers is also important if you use the https protocol (it has become a standard nowadays).
However, I would not rely on either the presence of all
X-Forwardedheaders, or the validity of their data.
例子
prefix 使用不带 X- 前缀的自定义头
X- 前缀的自定义头基本原理
Internet Engineering Task Force released a new RFC (RFC-6648), recommending deprecation of
X-prefix.
The
X-in front of a header name customarily has denoted it as experimental/non-standard/vendor-specific. Once it's a standard part of HTTP, it'll lose the prefix.
If it’s possible for new custom header to be standardized, use a non-used and meaningful header name.
The use of custom headers with
X-prefix is not forbidden but discouraged. In other words, you can keep usingX-prefixed headers, but it's not recommended and you may not document them as if they are public standard.
例子
Not recommended configuration:
Recommended configuration:
外部资源
负载均衡
负载平衡是一种有用的机制，可将传入的流量分布在几个有能力的服务器之间。
健康检查
健康监控对于所有类型的负载平衡都非常重要，主要是为了业务连续性。 被动检查会按照客户端的请求监视通过 Nginx 的连接失败或超时。
默认情况下启用此功能，但是此处提到的参数允许您调整其行为。 默认值为：
max_fails = 1和fail_timeout = 10s。
示例：
down 参数
有时我们需要关闭后端，例如 在维护时。 我认为良好的解决方案是使用 down 参数将服务器标记为永久不可用，即使停机时间很短也是如此。
如果您使用 IP 哈希负载平衡技术，那也很重要。 如果其中一台服务器需要临时删除，则应使用此参数进行标记，以保留客户端 IP 地址的当前哈希值。
注释对于真正永久禁用服务器或要出于历史目的而保留信息非常有用。
Nginx 还提供了一个备份参数，将该服务器标记为备份服务器。 当主服务器不可用时，将传递请求。 仅当我确定后端将在维护时正常工作时，我才很少将此选项用于上述目的。
示例
安全
防盗链
参考资料
最后更新于