當ssl被下游處理時，Nginx在http上同一個server_name塊上重寫爲http http

我們已經有這個問題很多年了，它開始咬我們的屁股。我們在django框架上爲用python編寫的客戶端運行一個站點。然後，我們使用nginx作爲django的網絡服務器/代理。這通常是最標準的設置，運行良好。當ssl被下游處理時，Nginx在http上同一個server_name塊上重寫爲http http

問題是我們的客戶端有更高的apache服務器。該服務器處理SSL終止，並通過正常的http傳遞請求給我們。 Apache服務器同時接受兩個域名上的http和https。

我們可以很容易地在http上重寫http到nginx的級別，但問題在於用戶可以刪除https並使用http。

有沒有辦法在nginx級別強制用戶返回https://secure.example.com，如果他們在http://secure.example.com。

由於

來源

2016-10-11 Julian Mulder

「我們可以很容易地重寫HTTP到HTTPS上nginx的水平，但問題進來，用戶可以刪除HTTPS，只是使用HTTP」 - 能你解釋得更好？當你說「重寫」你的意思是「重寫」？或者你的意思是「重定向」？ nginx知道原始請求是否使用https，以及如何？爲什麼你不能在apache中進行重定向？ –

是的，我的意思是重定向。 nginx不知道請求是否是https。我們不控制Apache，並試圖在這個級別完成任何事情是非常困難的。此時，我們正試圖查看是否可以在該IP上阻止端口80。 –

但是，如果nginx（以及隨後的Django）不知道請求是否是https，那麼nginx或Django怎麼可能決定需要重定向？我沒有看到任何方式沒有觸摸Apache。要麼apache必須做重定向，要麼apache應該傳遞原始請求是否是https（最好是第二個）的信息。 –

通常的技術是一種用於在代理處理SSL終止添加一個X-Forwarded-Proto報頭。上游應用程序可以在進入安全區域時有條件地重定向。

隨着nginx這可能使用map來完成：

map $http_x_forwarded_proto $insecure { 
    default 1; 
    https 0; 
} 

server { 
    ... 
    if ($insecure) { 
     return 301 https://$host$request_uri; 
    } 
    ... 
}

來源

2016-10-11 10:09:29

我已經試過了。不幸的是，它只是讓我重定向循環，因爲它一直認爲請求是不安全的。 –

它*是*以下游爲條件，爲您提供正確的標題。 –

當ssl被下游處理時，Nginx在http上同一個server_name塊上重寫爲http http

回答

相關問題