請求分析
請求分析 會將經過閘道的 HTTP Request 整理為趨勢、效能、來源與安全性維度，同時保留逐筆記錄供疑難排解。它分析的是閘道請求記錄，而非登入事件，也不包含未進入 HTTP 閘道的原始連接埠連線。
請求分析 透過 分析、記錄 與 WAF 記錄 分頁切換統計、請求詳情與防護事件。
啟用資料收集
請在 系統設定 → 記錄 啟用閘道請求記錄並設定保留週期，最少保留 1 天。Go 閘道預設會在 Runtime 目錄下的 logs 目錄，依日期寫入結構化 JSON 檔案；後台的 請求分析 頁面會直接讀取這些檔案。關閉記錄後不會產生新的分析資料；超過保留週期的檔案被清除後，也無法再用於歷史分析。記錄功能會增加儲存空間與寫入負擔，請依實際需求設定保留天數。
記錄來自127.0.0.1本機回環的記錄 預設關閉，因此本機健康檢查、同機反向 Proxy 或其他經由 127.0.0.1 進入閘道的請求，通常不會出現在清單中。需要排查本機呼叫鏈時再開啟；此選項只改變記錄範圍，不會變更回環來源的存取權限。
寫入作業採用非同步 Queue。設定頁面顯示累計捨棄數時，代表 Queue 曾經壅塞，部分請求未寫入磁碟；此數字不是遭閘道拒絕的請求數量。閘道因反向 Proxy Rate Limit 而直接中斷的請求，也不會寫入 Access Log。
修改記錄儲存目錄
在 系統設定 → 記錄 填寫儲存目錄，或按 選擇資料夾 選取閘道可存取的資料夾，再儲存。請求記錄頁也提供修改儲存路徑的入口。頁面分別顯示實際與預設目錄；留空或恢復預設後儲存即可回到預設位置。
瀏覽器顯示閘道伺服器的檔案系統；Docker 中是容器內路徑，需先掛載儲存空間。記錄目錄選擇器可瀏覽靜態內容瀏覽器隱藏的受保護目錄，但不代表能將它們公開為靜態網站。儲存時會檢查路徑與寫入權限，失敗後請依提示處理並重新讀取實際目錄。
變更目錄不會搬移舊記錄；儲存後的查詢、分析與保留期清理只使用目前目錄。舊目錄需另行保留或清理。記憶體目錄的記錄會在重新開機後遺失；外接持久化儲存可減少內部 FLASH 寫入。儲存後從外網發出請求，確認實際目錄與新記錄。
使用「分析」頁籤
可查看今天、近 7 天或近 30 天的資料。統計會依閘道時區彙整，最長範圍為 30 個連續日曆日；若記錄保留天數較短，較早日期自然不會有資料。
頂部指標包含請求數、獨立用戶端、5xx 錯誤率、P95 回應時間與出站流量。趨勢圖會比較總請求、4xx 與 5xx；下方還可拆分為：
- 請求目標：路徑、路由、Host 與上游；
- 存取來源：Referrer，以及 UTM 來源、媒介與活動；
- 國家與地區：依去重後的有效用戶端 IP 彙整；
- 用戶端：裝置類型、瀏覽器與作業系統；
- 回應：Status Code、方法與耗時區間；
- 驗證與安全性：驗證決策與 WAF 動作。
地理資訊來自 IP 定位快取。首次查看時可能顯示正在補全或部分涵蓋，可啟動地理資訊重新整理後稍候再查看。分析 API 只會回傳彙整後的國家與省市 Bucket，不會將用於彙整的用戶端 IP 清單傳回瀏覽器。損毀或欄位不完整的記錄不會計入統計，頁面會提示略過數量。
平均值、P95 與錯誤率適合發現趨勢，不等同於上游應用程式的完整效能追蹤。發現異常後請切換到 記錄 頁籤，依 Host、路徑、時間與 Status Code 定位特定請求。
使用「記錄」頁籤
解讀一筆記錄
| 欄位 | 用途 |
|---|---|
| 用戶端 IP／連線來源 IP | 比對真實訪客與閘道實際 TCP Peer，排查 CDN、反向 Proxy 與 Docker 連線路徑 |
| 方法、Host、路徑 | 判斷請求命中哪個服務 |
| 路由類型、上游 Target | 判斷 Host／路徑規則是否命中正確目標；靜態回應會顯示「靜態檔案」或「靜態目錄」，且沒有上游位址 |
| 驗證狀態 | 判斷結果來自工作階段、允許清單、本地豁免、進階驗證臨時憑據，或未授權 |
| 子網域規則組 ID／臨時憑據狀態 | 進階驗證命中時，確認實際規則組，以及目前為單次放行、已簽發、已續期或已重複使用 |
| Status Code、處理時間 | 區分閘道拒絕、上游錯誤與回應緩慢 |
請求記錄可能包含存取路徑、Query、來源 IP、User-Agent、驗證結果與上游 URL，應視為敏感維運資料處理。分享疑難排解片段前，請移除 Token、Query Parameter、內部 URL 與可識別個人的資訊。
靜態檔案與目錄回應由閘道直接讀取檔案系統，因此記錄中的上游 Target 為空。路由 Key 仍是服務 Host，Trace ID、驗證結果、WAF 動作、Status Code 與處理時間都會照常記錄；伺服器絕對路徑不會寫入請求記錄或 WAF 事件。設定與疑難排解請參閱靜態檔案與目錄回應。
建議的疑難排解順序
- 從外網送出一次可重現問題的請求。
- 搜尋對應的 Host 與路徑，確認請求是否到達閘道。
- 比對用戶端 IP，確認沒有將 Proxy IP 誤認為訪客。
- 檢查驗證狀態與存取原則。
- 再檢查上游 Target、Status Code 與應用程式本身的 Log。
依 Trace ID 查看完整鏈路
Request Log、WAF Log、系統事件與通知投遞使用統一 Trace ID 關聯記錄。可在 Request 分析 或 事件中心 選擇 Trace ID 查詢，或直接點選記錄中的 Trace ID，開啟完整鏈路追蹤。
追蹤頁依時間排列 Request、WAF 事件、系統事件、通知觸發與投遞，並標示每個資料來源為已找到、未找到或暫時無法使用。單一來源失敗時，其他內容仍會顯示。查無結果也可能是未啟用收集、記錄已過期，或舊記錄沒有統一 Trace ID。
Trace ID 也可能出現在閘道 Response Header、攔截頁或通知中。分享前仍須檢查 Host、路徑、來源 IP、Upstream 位址與通知內容；Trace ID 是關聯鍵，不是已去識別化的公開憑據。
如果記錄中完全找不到請求，請先確認測試流量是否來自 127.0.0.1，以及回環記錄開關是否已開啟。排除本機請求後，問題通常發生在 DNS、CDN、Tunnel、路由器或連接埠發布等更前端的環節；不要一開始就修改映射規則。
如果只有部分請求缺少記錄，請檢查閘道 Rate Limit 是否直接中斷連線，以及記錄設定頁面是否出現 Queue 捨棄警告。若 Status Code 來自閘道而非上游，請繼續檢查身分驗證、可見性、WAF 與映射；若已顯示正確的上游 Target，再轉往應用程式本身的 Log。
託管 Cloudflare Tunnel 開啟 Pseudo IPv4 → Overwrite Headers 時，IPv6 訪客的初始邊緣 Header 可能是 240.0.0.0/4。支援此模式的 fn-knock 會在託管專用入口驗證 CF-Connecting-IPv6，並將「Client IP」還原為真實公網 IPv6；「Connection source IP」仍反映本機 Tunnel 路徑。升級後若仍記錄 Class E 位址，請檢查是否使用手動 Origin，或 Header 是否缺少／重複；手動 Origin 建議將 Pseudo IPv4 改為 Off 或 Add Header。不要把 240.0.0.0/4 加入允許清單來繞過問題。
啟用子網域進階驗證後，驗證結果 子網域規則放行 代表請求已透過進階驗證放行。詳細資訊中的規則組 ID 可用來定位觸發設定；單次請求放行 表示本次請求命中規則但未建立持久憑據，常見於首次 Cookie 探測、不儲存 Cookie 的用戶端、WebSocket Upgrade 或持久化降級；已簽發 表示本次建立持久憑據，已續期 表示重新計算閒置有效期，已重複使用 表示繼續沿用既有憑據。規則行為請參閱子網域進階驗證。
處理可疑 IP
確認為實際攻擊來源後，可從記錄直接前往全域封鎖清單或 IP 允許清單進行處置。操作前請先排除共用出口與前置 Proxy IP，並保留時間、Host、路徑等 Context。