踩坑备忘录—Nginx反向代理之server_name与ip
我们的系统依赖一个第三方的服务，该服务是通过IP限制访问权限的。出于安全考虑，我们的系统会校验证书，因此我们采用Nginx反向代理去访问该服务。该服务迁移到cloud上之后，我们系统出现了问题。
Nginx的配置文件如下所示：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
http { upstream backend.example.com { server backend1.example.com:443; } server { listen 80; server_name www.example.com; location /upstream { proxy_pass https://backend.example.com; proxy_ssl_certificate /etc/nginx/client.pem; proxy_ssl_certificate_key /etc/nginx/client.key; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers HIGH:!aNULL:!MD5; proxy_ssl_trusted_certificate /etc/nginx/trusted_ca_cert.crt; proxy_ssl_verify on; proxy_ssl_verify_depth 2; } } } |
Debug
在出现线上问题的时候，第一时间检查了配置文件的改动记录 ⇒ 配置文件没有改到。
接着检查了，证书是否过期⇒没有过期。
通过域名curl请求 ⇒ 第三方服务正常，证书正确。
在我们没有任何改动的情况下，第三方服务也是单纯地做了迁移，然后就挂了。
思考了很久之后，Nginx没有任何改动，那么出问题的一定不是我们。那么出问题一定是第三方，最直接的方式是联系第三方提供商，联系渠道很繁琐，时间成本也会很高。为了快速修复问题，我们决定盲调Bug。
尝试解决
第一次尝试，已知curl请求一切正常。尝试着将upstream干掉，直接写道proxy_path中。依旧是失败，错误日志中出现了”https://1.1.1.1:443 TLS handshake failed”。推断，proxy_path会将域名转换成ip。
第二次尝试，尝试检查curl ip来访问服务。失败。推断，IP和域名指向了两个不同的服务。到这里算是找到root cause了。
解决思路：反向代理时候，通过域名访问而不是IP访问。
查询文档，发现可以使用配置项：proxy_ssl_server_name，该配置项默认值是off，需要将一些内容写到配置文件中：
|
1 |
proxy_ssl_server_name on; |
第三次尝试，将proxy_ssl_server_name on写入到配置文件中。成功。
什么是server_name
服务器名称指示（Server Name Indication, SNI）是对TLS协议的扩展。在握手过程开始时，通过该协议，客户端指示其尝试连接的主机名。该协议允许服务器上的同一个IP和TCP端口拥有多个证书，因此允许同一个IP地址为多个HTTPS网站提供服务，且无需所有网站使用相同的证书。
from:https://www.realks.com/2021/03/07/nginx-proxy-ssl-server-name/