先说说奇葩的需要：https转其余网站的http
在我的项目里用iframe内嵌其余网站，这个“其余网站”不是咱们开发的，并且是http，
但浏览器会默认阻止从https网站向http地址发动申请
因而初步的解决方案是：用咱们本人的服务器nginx转发一次，尽管服务器到“其余网站”的传输还是明文，但至多能够做到甩锅（至多用户到咱们的服务器的传输是SSL......）
而后这个“其余网站”就呈现了有限重定向问题。
另外，依据以往的经验，在给WordPress加https的时候，也可能会遇到有限重定向的问题。
起因
实质上是因为：“其余网站”的服务程序具备申请头校验。
通常来说，nginx转发的申请，是带有原始申请头信息的申请。
比方：
nginx服务器的地址是https://server1.domin:1111
生产服务器的地址是http://server2.domin:2222
浏览器向https://server1.domin:1111发动申请
此时，尽管nginx把申请代理到了http://server2.domin:2222
但因为一系列的参数设置，http申请头中的信息还是https://server1.domin:1111
这种状况下，如果“其余网站”的服务程序（Apache或nginx）中退出了申请头校验，
也就是说，如果端口不是2222，就重定向；
如果地址不是server2.domin，就重定向。
而咱们的nginx曾经把申请头改成了原始信息，天然不能通过他们的验证，所以就会被强制重定向了。
如图，它把我的38004端口的申请重定向到了默认的443,阐明对方服务器有地址校验，而且重定向只扭转了端口。
而如果我的nginx恰好也用的443,就会有限重定向了。
解决
咱们先来看看通常应用的nginx的重写参数：
server { listen 38002 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host $host; proxy_set_header X-Real_IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr:$remote_port; proxy_pass http://server2.domin:2222/; }}这种状况下，就是间接在代理的申请中，退出原始申请头信息
那么咱们怎么改呢？
咱们要让对方服务器认为，nginx发过来的申请不是代理过来的，而是间接发过来的。
再换种形式说，此时nginx的作用不再是反向代理，而是正向代理，目标是暗藏真正的申请信息，让对方服务器认为就是nginx间接申请的对方服务器。
所以咱们要把ip、端口等等参数间接写死。
server { listen 443 ssl; server_name server1.domin; ssl_certificate server1.domin.cer; ssl_certificate_key server1.domin.key; location / { proxy_set_header Host server2.domin; // 对方服务器的域名 proxy_set_header X-Real-IP 123.123.123.123; // 对方服务器的实在地址，从控制台中找到 proxy_set_header X-Forwarded-For $123.123.123.123:80; proxy_set_header X-Forwarded-Host server2.domin; // 对方服务器的域名 proxy_set_header X-Forwarded-Port 80; // 对方服务器的端口 proxy_pass http://server2.domin:2222/; }}于是代理过程就变成了这样：
总结
在咱们不得不用nginx代理，并且无奈让对方配合的状况下
只有把http中的申请头信息替换为对方网站的申请头信息（而不是应用原始信息）
就能够通过对方服务器的host验证了。
工夫仓促，有些中央可能说的不准，但目前能用，如有谬误欢送斧正。
本文只公布segmentfault，禁止转载，如在其余平台看到请举报。