AWSJ後面的NodeJS將http重定向到https失敗的健康檢查

-1

我配置了ELB以打開80和443，其中443配置了SSL。兩個ELB端口指向實例的80端口。 ELB的heatlh檢查使用ping目標HTTP：80/index.html。它曾經工作，直到我最近決定開始將http重定向到https。AWSJ後面的NodeJS將http重定向到https失敗的健康檢查

現在下面的代碼是在server.js（內//我是新加入的代碼的代碼）：

// 
app.use(function(req, res, next) { 
    if (config.env === 'prod' && req.get('X-Forwarded-Proto') !== 'https') { 
     console.log("redirecting") 
     console.log('https://' + req.get('Host') + req.url) 
     res.set('X-Forwarded-Proto', 'https'); 
     res.redirect('https://' + req.get('Host') + req.url); 
    } 
    else 
     next(); 
}); 
// 

app.use(express.static(path.join(__dirname, 'home'))); 
app.set('trust proxy'); // enable this to trust the proxy 

app.listen(app.get('port'), function() { 
    console.log('Express server listening on port ' + app.get('port')); 
}); 

app.get("/*", function(req, res, next) { 
    res.sendFile(path.join(__dirname, 'home/index.html')); 
});

我認爲上述要求將重定向所有請求到服務器ELB但以https協議。

但是服務器啓動打印：

redirecting 
https://10.x.x.xx/index.html

然後是ELB未能爲https://10.x.x.xx/inde.html不可用。

但是index.html的位置正好在{domain} /下。

我認爲我重定向的方式可能是錯誤的 - 但我不知道如何解決它。

來源

2017-02-27 jamesdeath123

負載均衡器運行狀況檢查請求將不具有x-forwarded-proto標頭，因爲它們尚未從客戶端轉發，它們直接來自負載均衡器。在做重定向之前，您可能需要檢查頭是否存在。

另外我對你的SSL設置有點困惑。您是否在負載均衡器上進行SSL終止，還在EC2服務器上提供SSL證書？您說「兩個ELB端口指向實例的80端口」，這意味着您沒有在EC2服務器上提供SSL證書，所以您的運行狀況檢查URL應爲http而不是https。

而且這條線，你重定向前右側有完成什麼都沒有：

res.set('X-Forwarded-Proto', 'https');

來源

2017-02-27 22:01:52

我認爲這將設置這樣的標題所有要求？由於只有沒有這個頭部的請求才會進入這一行？ – jamesdeath123

關於SSL - 目前，http：// {域}和https：// {域}都將工作;只有http：{域}纔會有保護。 SSL在ELB上完成，最終將所有請求指向EC2的端口80. – jamesdeath123

「x-forwarded-proto」頭文件的全部內容是讓負載平衡器設置它。你爲什麼要在服務器上覆蓋它？並且在發出重定向之前通過將請求設置爲請求，因爲該請求隨後被丟棄，因此不會執行任何操作。 –

我的解決辦法是重新定向之前，檢查健康API路線。 AWS上的負載均衡

建立健康檢查/ API /健康
添加條件

if (config.env === 'prod' && req.get('X-Forwarded-Proto') !== 'https' && req.url !== '/api/health') { // redirect }

來源

2017-02-27 22:06:54 paqash

AWSJ後面的NodeJS將http重定向到https失敗的健康檢查

回答

相關問題