先說說奇葩的需求：https轉(zhuǎn)其他網(wǎng)站的http

在項目里用iframe內(nèi)嵌其他網(wǎng)站，這個“其他網(wǎng)站”不是我們開發(fā)的，并且是http，
但瀏覽器會默認(rèn)阻止從https網(wǎng)站向http地址發(fā)起請求

因此初步的解決方案是：用我們自己的服務(wù)器nginx轉(zhuǎn)發(fā)一次，雖然服務(wù)器到“其他網(wǎng)站”的傳輸還是明文，但至少可以做到甩鍋（至少用戶到我們的服務(wù)器的傳輸是SSL......）

然后這個“其他網(wǎng)站”就出現(xiàn)了無限重定向問題。

另外，根據(jù)以往的經(jīng)歷，在給WordPress加https的時候，也可能會遇到無限重定向的問題。

原因

本質(zhì)上是因為：“其他網(wǎng)站”的服務(wù)程序具有請求頭校驗。

通常來說，nginx轉(zhuǎn)發(fā)的請求，是帶有原始請求頭信息的請求。
比如：

nginx服務(wù)器的地址是https://server1.domin:1111

生產(chǎn)服務(wù)器的地址是http://server2.domin:2222

瀏覽器向https://server1.domin:1111發(fā)起請求

此時，雖然nginx把請求代理到了http://server2.domin:2222但由于一系列的參數(shù)設(shè)置，http請求頭中的信息還是https://server1.domin:1111

這種情況下，如果“其他網(wǎng)站”的服務(wù)程序（Apache或nginx）中加入了請求頭校驗，也就是說，如果端口不是2222，就重定向；

如果地址不是server2.domin，就重定向。

而我們的nginx已經(jīng)把請求頭改成了原始信息，自然不能通過他們的驗證，所以就會被強制重定向了。

如圖，它把我的38004端口的請求重定向到了默認(rèn)的443,說明對方服務(wù)器有地址校驗，而且重定向只改變了端口。

而如果我的nginx恰好也用的443,就會無限重定向了。

解決

我們先來看看通常使用的nginx的重寫參數(shù)：

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/;
    }
}

這種情況下，就是直接在代理的請求中，加入原始請求頭信息

那么我們怎么改呢？

我們要讓對方服務(wù)器認(rèn)為，nginx發(fā)過去的請求不是代理過去的，而是直接發(fā)過去的。

再換種方式說，此時nginx的作用不再是反向代理，而是正向代理，目的是隱藏真正的請求信息，讓對方服

務(wù)器認(rèn)為就是nginx直接請求的對方服務(wù)器。

所以我們要把ip、端口等等參數(shù)直接寫死。

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; // 對方服務(wù)器的域名
        proxy_set_header X-Real-IP 123.123.123.123; // 對方服務(wù)器的真實地址，從控制臺中找到
        proxy_set_header X-Forwarded-For $123.123.123.123:80;
        proxy_set_header X-Forwarded-Host server2.domin; // 對方服務(wù)器的域名
        proxy_set_header X-Forwarded-Port 80; // 對方服務(wù)器的端口
        proxy_pass http://server2.domin:2222/;
    }
}

于是代理過程就變成了這樣：

總結(jié)

在我們不得不用nginx代理，并且無法讓對方配合的情況下

只要把http中的請求頭信息替換為對方網(wǎng)站的請求頭信息（而不是使用原始信息）

就可以通過對方服務(wù)器的host驗證了。

時間倉促，有些地方可能說的不準(zhǔn)，但目前能用，如有錯誤歡迎指正。

以上就是nginx反向代理后無限重定向的問題解決方法的詳細(xì)內(nèi)容，更多關(guān)于nginx反向代理重定向的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論