标题:【Nginx30】Nginx学习:代理模块(四)响应头与SSL
Nginx学习:代理模块(四)响应头与SSL
响应头相关的配置也和我们之前在 FastCGI 系列学过的响应头配置是类似的,这一块也比较简单。而另一部分则是 Proxy 模块另一个特有的功能,SSL 相关的配置。不过这一块吧,一是配置比较麻烦,二是平常使用到的也比较少,所以我也是以学习了解的状态来进行的,偷个懒,不会进行相应的配置测试。有兴趣的小伙伴可以自己配一配哦。
今天所有的配置都可以在 http、server、location 下进行配置,有特殊情况的我会单独说。
Proxy响应头操作
响应头主要针对的是响应的操作,其实也就是对于后端服务返回的响应头,我们可以进行一些显示、隐藏、忽略之类的操作。这个之前在 FastCGI 学习时也都接触过了,所以咱们还是先了解一下这几个配置指令,然后再简单测试一下就好了。
proxy_headers_hash_bucket_size
设置 proxy_hide_header 和 proxy_set_header 指令使用的哈希表的桶大小。
proxy_headers_hash_bucket_size size;
默认值 64 。
proxy_headers_hash_max_size
设置 proxy_hide_header 和 proxy_set_header 指令使用的哈希表的最大大小。
proxy_headers_hash_max_size size;
默认值 512 ,关于这个和上面那个配置指令,都是和 设置哈希表 有关的,这个之前在 Nginx学习:响应头与Map变量操作 https://mp.weixin.qq.com/s/2pXjPD9_c-mYUMQNcwjDCA 中已经学习过了,不记得的小伙伴可以回去看下哦。
proxy_hide_header
默认情况下,Nginx 不会将代理服务器的响应中的标头字段“Date”、“Server”、“X-Pad”和“X-Accel-...”传递给客户端。
proxy_hide_header field;
没有默认值,proxy_hide_header 指令设置不会传递的附加字段。相反,如果需要允许传递字段,则可以使用 proxy_pass_header 指令。
proxy_pass_header
允许将禁用的标头字段从代理服务器传递到客户端。
proxy_pass_header field;
禁用标头就是 proxy_hide_header 中说的那些默认头字段,主要是 “Date”, “Server”, “X-Pad”, 和 “X-Accel-...” 这些。和 proxy_hide_header 是反过来的,同时出现的话也和 FastCGI 中是一样的,就看谁后设置。
proxy_ignore_headers
禁用对来自代理服务器的某些响应头字段的处理。
proxy_ignore_headers field ...;
以下字段可以忽略:“X-Accel-Redirect”、“X-Accel-Expires”、“X-Accel-Limit-Rate”(1.1.6)、“X-Accel-Buffering”(1.1.6) 、“X-Accel-Charset”(1.1.6)、“Expires”、“Cache-Control”、“Set-Cookie”(0.8.44)和“Vary”(1.7.7)。
如果未禁用,则处理这些标头字段具有以下效果:
“X-Accel-Expires”、“Expires”、“Cache-Control”、“Set-Cookie”、“Vary”设置响应缓存的参数
“X-Accel-Redirect”执行到指定 URI 的内部重定向
“X-Accel-Limit-Rate”设置向客户端传输响应的速率限制
“X-Accel-Buffering”启用或禁用响应缓冲
“X-Accel-Charset”设置响应的所需字符集
主要就是针对这些字段的特殊效果,如果不设置忽略,就会产生相应的效果,如果设置忽略了,就不会出现这些能力。
响应头测试
简单测试两个吧。
proxy_hide_header oopp;
#proxy_pass_header oopp;
后端 PHP 代码我们还是之前我们测试用过的那个,直接指定 oopp 这样一个自定义的响应头。
// fastcgi1/5.php
<?php
header('oopp: 123');
然后进行测试就好了。
SSL
这里的 SSL 配置主要是代理服务器与后端服务器的安全传输,不过说实话,大部分情况下我们会在内网使用反向代理进行负载均衡或部分应用的代理配置,很少会进行外网反向代理。即使有的话,不使用任何配置,直接去代理 HTTPS 也是可以的,代理请求的内容通过 WireShark 抓取的也是加密的内容。只不过使用 Proxy 本身的 SSL 配置指令,会验证证书情况,保证完整的 SSL 验证握手过程,安全性没得说。当然,这也不是没有代价的,加解密肯定是要耗费系统资源的。
因此,这一块的内容我们了解一下就好了,我也不做演示了,确实没用过,概念也略有模糊的地方。如果确实有特殊的需要,比如说我们的后端服务器必须保障数据安全的话,并且是远程的传输,不在内网范围内,就可以通过下面的设置来进行安全传输配置。
如果对这一块有了解或者在实战中使用过有心得的大佬们看到了,可以评论留言带咱们一起学习一下哦。
proxy_ssl_verify
启用或禁用代理 HTTPS 服务器证书的验证。
proxy_ssl_verify on | off;
默认值是 off 。
proxy_ssl_certificate
指定带有 PEM 格式证书的文件,用于向代理 HTTPS 服务器进行身份验证。
proxy_ssl_certificate file;
没有默认值,从 1.21.0 版本开始,文件名中可以使用变量。
proxy_ssl_certificate_key
使用 PEM 格式的密钥指定一个文件,用于向代理 HTTPS 服务器进行身份验证。
proxy_ssl_certificate_key file;
可以指定值 engine:name:id 代替文件 (1.7.9),该文件从 OpenSSL 引擎名称加载具有指定 id 的密钥。从 1.21.0 版本开始,文件名中可以使用变量。
proxy_ssl_ciphers
指定对代理 HTTPS 服务器的请求启用的密码。
proxy_ssl_ciphers ciphers;
默认值是 DEFAULT,密码以 OpenSSL 库可以理解的格式指定。可以使用“openssl ciphers”命令查看完整列表。
proxy_ssl_conf_command
在与代理 HTTPS 服务器建立连接时设置任意 OpenSSL 配置命令。
proxy_ssl_conf_command name value;
没有默认值,使用 OpenSSL 1.0.2 或更高版本时支持该指令。可以在同一级别上指定多个 proxy_ssl_conf_command 指令。当且仅当当前级别上没有定义 proxy_ssl_conf_command 指令时,这些指令才从先前的配置级别继承。请注意,直接配置 OpenSSL 可能会导致意外行为。
proxy_ssl_crl
指定一个 PEM 格式的带有撤销证书 (CRL) 的文件,用于验证代理 HTTPS 服务器的证书。
proxy_ssl_crl file;
没有默认值。
proxy_ssl_name
允许覆盖用于验证代理 HTTPS 服务器证书并在与代理 HTTPS 服务器建立连接时通过 SNI 传递的服务器名称。
proxy_ssl_name name;
默认情况下,使用 proxy_pass URL 的主机部分,也就是默认值是 $proxy_host
。
proxy_ssl_password_file
指定一个包含密钥密码短语的文件,其中每个密码短语在单独的行中指定。
proxy_ssl_password_file file;
没有默认值,加载密钥时会依次尝试密码短语。
proxy_ssl_protocols
启用对代理 HTTPS 服务器的请求的指定协议。
proxy_ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];
默认值是 TLSv1 TLSv1.1 TLSv1.2 。
proxy_ssl_server_name
在与代理 HTTPS 服务器建立连接时,启用或禁用通过 TLS 服务器名称指示扩展(SNI、RFC 6066)传递服务器名称。
proxy_ssl_server_name on | off;
默认是 off 。
proxy_ssl_session_reuse
确定在使用代理服务器时是否可以重用 SSL 会话。
proxy_ssl_session_reuse on | off;
默认值是 on ,如果日志中出现“SSL3_GET_FINISHED:digest check failed”错误,请尝试禁用会话重用。
proxy_ssl_trusted_certificate
指定具有 PEM 格式的受信任 CA 证书的文件,用于验证代理 HTTPS 服务器的证书。
proxy_ssl_trusted_certificate file;
没有默认值。
proxy_ssl_verify_depth
在代理的 HTTPS 服务器证书链中设置验证深度。
proxy_ssl_verify_depth number;
默认值是 1 。
总结
今天的内容超级简单吧,就跟看文档一样的,就一个简单的响应头相关的两个配置指令的测试。虽说这样的学习效率很差,但是,如果确实是不经常使用的内容,混个眼熟也没什么不好。知识浩瀚,我们程序员似乎总也学不完一样,编程语言就不说了,前两天还是大数据,过两天就是人工智能,门都没入呢别的又来了。先不说各种概念框架的底层原理,光是文档估计看全都没几个人吧。所以,咱也不能太浪费自己的精力,有的时候,总是要有一些取舍的。到这里,将来如果真的需要的时候,起码第一时间能马上想起来,完了再针对具体的业务场景进行深入的研究和学习,也是不错的选择哦。
参考文档:
http://nginx.org/en/docs/http/ngx_http_proxy_module.html