Egg 前置代理模式

一般來說我們的服務都不會直接接受外部的請求，而會將服務部署在接入層之后，從而實現多臺機器的負載均衡和服務的平滑發(fā)布，保證高可用。

在這個場景下，我們無法直接獲取到真實用戶請求的連接，從而無法確認用戶的真實 IP，請求協議，甚至請求的域名。為了解決這個問題，框架默認提供了一系列配置項來讓開發(fā)者配置，以便基于和接入層的約定（事實標準）來讓應用層獲取到真實的用戶請求信息。

開啟前置代理模式

通過 config.proxy = true，可以打開前置代理模式：

// config/config.default.js

exports.proxy = true;

注意，開啟此模式后，應用就默認自己處于反向代理之后，會支持通過解析約定的請求頭來獲取用戶真實的 IP，協議和域名。如果你的服務未部署在反向代理之后，請不要開啟此配置，以防被惡意用戶偽造請求 IP 等信息。

config.ipHeaders

開啟 proxy 配置后，應用會解析 X-Forwarded-For 請求頭來獲取客戶端的真實 IP。如果你的前置代理通過其他的請求頭來傳遞該信息，可以通過 config.ipHeaders 來配置，這個配置項支持配置多個頭（逗號分開）。

// config/config.default.js

exports.ipHeaders = 'X-Real-Ip, X-Forwarded-For';

config.maxIpsCount

X-Forwarded-For 等傳遞 IP 的頭，通用的格式是：

X-Forwarded-For: client, proxy1, proxy2

我們可以拿第一個作為請求的真實 IP，但是如果有惡意用戶在請求中傳遞了 X-Forwarded-For 參數來偽造其在反向代理之后，就會導致 X-Forwarded-For 拿到的值不準確了，可以被用來偽造請求 IP 地址，突破應用層的一些 IP 限制。

X-Forwarded-For: fake, client, proxy1, proxy2

為了避免此問題，我們可以通過 config.maxIpsCount 來配置前置的反向代理數量，這樣在獲取請求真實 IP 地址時，就會忽略掉用戶多傳遞的偽造 IP 地址了。例如我們將應用部署在一個統(tǒng)一的接入層之后（例如阿里云 SLB），我們可以將此參數配置為 1，這樣用戶就無法通過 X-Forwarded-For 請求頭來偽造 IP 地址了。

// config/config.default.js

exports.maxIpsCount = 1;

此配置項與 koa 提供的 options.maxIpsCount 作用一致。

config.protocolHeaders

開啟 proxy 配置后，應用會解析 X-Forwarded-Proto 請求頭來獲取客戶端的真實訪問協議。如果你的前置代理通過其他的請求頭來傳遞該信息，可以通過 config.protocolHeaders 來配置，這個配置項支持配置多個頭（逗號分開）。

// config/config.default.js

exports.protocolHeaders = 'X-Real-Proto, X-Forwarded-Proto';

config.hostHeaders

開啟 proxy 配置后，應用仍然還是直接讀取 host 來獲取請求的域名，絕大部分反向代理并不會修改這個值。但是也許有些反向代理會通過 X-Forwarded-Host 來傳遞客戶端的真實訪問域名，可以通過在 config.hostHeaders 中配置，這個配置項支持配置多個頭（逗號分開）。

// config/config.default.js

exports.hostHeaders = 'X-Forwarded-Host';