從 nginx 接到請求，到回 403 或轉給被保護網站、再把回應送回去，中間有五個檢查階段。本篇說明每個階段看什麼、在哪一點決定攔下、放行時往後端帶了什麼標頭、以及為什麼 real_ip 模組被刻意設成不會生效。

一、五個階段

ModSecurity 把一筆交易切成五個 phase，connector 把它們掛在 nginx 處理請求的不同時點上。規則各自宣告自己屬於哪個 phase；同一個 phase 內的規則依載入順序執行。

二、403 是誰回的

949110 的動作是 deny，引擎把交易標成 interrupted，connector 讓 nginx 以 403 結束這個請求。三件事值得寫清楚：

三、nginx 自己先擋掉的東西

有些請求連 phase 1 都到不了，因為 nginx 在解析階段就拒絕了。這類請求不會出現在 audit.log，也就不會變成平台事件。實測到的一個：

四、放行時往後端帶什麼

這是容器內 includes/proxy_backend.conf 生效中的內容（後端位址已換成文件用的示範值）：

proxy_set_header Host $host;
proxy_set_header Proxy "";
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_buffering off;
proxy_connect_timeout 60s;
proxy_read_timeout 36000s;
proxy_redirect off;
proxy_pass_header Authorization;
proxy_pass http://192.168.0.111:8000;
set_real_ip_from 127.0.0.2;
real_ip_header CF-Connecting-IP;
real_ip_recursive on;

被保護網站看到的 TCP 來源永遠是主機 B（docker MASQUERADE 後的實體網卡 IP）。要知道真實訪客，後端得讀 XFF 或 CF-Connecting-IP，而且只該在來源是主機 B 時才信。BeakPlatform 這一側的做法是 TRUSTED_PROXY_IPS 設成防禦節點的 IP、只信任該來源送的 CF-Connecting-IP；其他後端要自己做等價的事。

五、為什麼 real_ip 刻意設成不會生效

nginx 的 real_ip 模組原本的用途是：來源在 set_real_ip_from 清單內時，把 $remote_addr 換成 real_ip_header 指定的標頭值。直覺的設法是 set_real_ip_from 172.18.0.250（cloudflared），這樣 nginx 眼中的來源就會變成真實訪客。本安裝包沒有這樣做，而是設成 127.0.0.2，一個永遠不會是來源的位址。三段推理：

代價是 nginx 的 access log 與 X-Real-IP 都是 cloudflared 的 IP，看起來像「所有請求都來自同一個位址」。這是刻意的，攻擊者歸因在 Vector 做、證據在 audit.log 的 request.headers 裡，兩邊都沒有損失。原系列第 5 篇第一節從整體信任邊界的角度談同一件事。

六、誰打得到 8080

容器內另有兩個 nginx 自己回應、不經後端的路徑：/healthz（回 200 OK，compose 的 healthcheck 用）與 /metrics/nginx（stub_status，只允許 127.0.0.0/24）。它們在 location_common.conf 裡、關掉了 access log，但仍然經過 ModSecurity，用它們做驗證時一樣會有規則命中。

七、實測：五種請求的結果

2026-09-26 從 ADMIN_IPS 內的管理機用 IP 直打防禦節點 8080，被保護網站是 BeakPlatform。原始輸出在 /opt/tmp/verify/20260926-waf-doc-probe.log。

八、兩個容器怎麼分流

cloudflared 的 ingress 規則決定請求進哪個 WAF 容器。cf_tunnel.py 產生的規則依序比對，同一個 hostname 帶 path 的排前面：

兩個容器都不做 hostname 比對（SERVER_NAME "_"），分流責任完全在 cloudflared。內網直打時沒有 cloudflared，8080 一律是主站、8082 一律是歡迎頁。