Daily Archives: 2022年2月18日
踩坑备忘录—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/
View Details
docker export import后，导入镜像，启动时的错误，Error response from daemon: No command specified
Docker的流行与它对容器的易分享和易移植密不可分，用户不仅可以把容器提交到公共服务器上，还可以把容器导出到本地文件系统中。同样，我们也可以把导出的容器重新导入到Docker运行环境中。Docker的容器导入导出分别用import和export命令完成。
View Detailsdocker: Error response from daemon: No command specified. 解决
一般来说产生这个报错是因为启动的容器是被docker export出来的镜像。
Command可以通过下面命令查询到：docker ps -a --no-trunc
查询到Command之后，运行容器：docker run --name nginx-import-test -d -p 4000:80 nginx-import-test:1.0 /docker-entrypoint.sh nginx -g 'daemon off;'