Traefik 3.6 在 2025 年 11 月 10 日的 KubeCon North America 上發表，帶進來的 multi-layer routing 打破了反向代理設定檔一貫的扁平結構——router 之間第一次可以用 parentRefs 建立父子關係，讓上層先跑 middleware 處理認證、加上 header，下層再拿這些被加工過的資訊做路由決策。同一份設定裡想同時做 SSO、灰度、A/B 測試，過去在 Nginx Ingress 得靠 annotation 疊字串、在 Envoy 得寫一整套 EnvoyFilter，現在拆成一棵樹就結束。
這次改版另外兩個焦點——Knative provider 把 serverless 冷啟動流量收進主要設定、Gateway API v1.4 的 BackendTLSPolicy 從 experimental 進 stable——放在多層路由的脈絡下才看得清楚：Traefik 押寶的是「所有 north-south 流量走同一個 proxy、同一份設定」。
扁平的 router table 為什麼撐不住
傳統 reverse proxy 的心智模型是一張扁平表：每個 route 一列，每列自己列好 match rule、middleware chain、backend service。Nginx 的 server + location 塊、HAProxy 的 frontend + backend、傳統 Traefik router 都是這種形狀。單一路由設定看起來乾淨，但當同一組 middleware（例如 JWT 驗證、rate limit、CORS）要套在幾十條 route 上時，維護成本會急速惡化。
Kubernetes Ingress 走出來的路更暴力——把所有邏輯塞進 annotation 字串。要做「認證通過後根據使用者 tier 分流到不同 backend」這種需求，得在 nginx.ingress.kubernetes.io/configuration-snippet 裡塞一段 Lua 或 nginx.conf 片段。這種設定沒有型別檢查、CI 難跑、換 controller 幾乎不能重用，實務上多半是複製貼上疊到沒人看得懂為止。這正是 3 月 ingress-nginx 官方 EOL 後大家爭相找替代品的推力之一。
Envoy 那邊 EnvoyFilter 提供了完整的可程式化能力，但代價是每次改路由都要寫 XDS 或走 WASM plugin，門檻對大多數應用團隊過高。中間需要一個「宣告式、可組合、看得懂」的中間態，multi-layer routing 就是 Traefik 對這個位置的答案。
parentRefs 把 middleware 跟 rule 分家
Traefik 3.6 引入三種 router：
- Root router：掛在 entryPoint 上，負責 TLS、observability、共用 middleware。
- Intermediate router：用
parentRefs指向 root 或另一個 intermediate，可以再有 child，但本身不能定義 service。 - Leaf router：必須定義 service，不能有 entryPoints 或 TLS 設定，只負責最後一哩的分流決策。
Request 進來後的流程變成：EntryPoint → Root Router → Middleware → Child Router → Service。中間任何一層都可以插 middleware 改寫 request，下一層拿到的已經是被加工後的版本。
實際 YAML 長這樣：
1 | http: |
jwt-auth middleware 解 token 之後在 request 上塞一個 X-Customer-Tier header，兩個 child router 各自 match 這個 header 決定去哪個 backend。這在扁平 router table 底下要嘛做不到、要嘛得靠 forward auth service 加自訂 header 匹配疊出來，維護性差得多。
Docker 跟 Gateway API provider 沒接上
Multi-layer routing 目前只支援 File provider（YAML、TOML、JSON）、KV store（Consul、etcd、Redis、ZooKeeper）以及 Kubernetes CRD（IngressRoute）三條路。Docker provider、Kubernetes Ingress 跟 Gateway API 都無緣。
這個限制不是技術做不到，而是資料模型的落差。Docker labels 跟 Kubernetes Ingress 都沒有原生表達父子關係的語法；Gateway API 有 parentRefs 這個欄位但語意跟 Traefik 的 parent router 是兩回事——前者指 HTTPRoute 掛到哪些 Gateway 上、後者指 router 之間的層級關係。硬套會讓兩邊語意衝突。
實際影響很直接：想用 multi-layer routing，Kubernetes 環境上只能走 IngressRoute CRD，Docker Compose 環境要把 label 拿掉、改成 file provider。對很多小型團隊「Docker Compose + Traefik labels」是預設起手式，這個 gap 短期內是實務障礙。長期看 Traefik 官方應該會補上，但 3.6 這個版本要用 multi-layer routing 就得接受這個成本。
Knative provider 把 serverless 收進主設定
Knative 過去在 Traefik 生態裡是尷尬存在——它有自己的 Kourier 或 Contour 做 ingress，跟主應用的反向代理分開。當一個叢集裡同時跑常駐 API、批次 job、事件驅動 function，光是網路層就要維護兩三套。
3.6 的 Knative provider 把這件事收攏。experimental flag 打開後：
1 | experimental: |
Traefik 會自動發現 Knative Service 資源、追蹤 scale-to-zero 狀態、把流量正確導到 activator 或 pod。冷啟動時 request 打過來不會 502，而是排在 activator 那邊等新 pod 起來——這是 Knative 原生 ingress 該做的事，只是現在同一個 proxy 也做得到。
搭配 weighted routing 跟 tag-based routing，藍綠、金絲雀、A/B 測試在 Knative Service 上直接由 Traefik 的 router 處理，不用再拉一層 Istio 或另外裝 Kourier。
適合誰？跑 Knative 的團隊本來就少，主要在事件驅動架構或 ML inference platform。這個 provider 讓那些原本就用 Traefik 的團隊多一個選項，不用因為要跑一個 Knative service 就整套換 ingress。
Gateway API v1.4 兩個功能升 stable
Gateway API v1.4 有兩個過去在 experimental channel 的功能升到 standard，Traefik 3.6 跟進支援：
BackendTLSPolicy 讓 Gateway 到 backend service 之間可以強制 TLS 加密。過去這段路徑要嘛靠 sidecar（Istio、Linkerd）、要嘛靠 backend 自己開 HTTPS，Gateway 這一層很難統一管理憑證。BackendTLSPolicy 用 CRD 宣告方式指定「往 service X 的流量要用 CA Y 驗證」，跟 mTLS 或 zero-trust 網路的方向對齊。
SupportedFeatures status reporting 是 UX 改善——過去用 Gateway API 常見的痛是「同一份 HTTPRoute 在不同 controller 底下行為不一樣」，因為每個實作對 conformance profile 支援程度不同。現在 controller 會在 Gateway status 裡明確列出支援哪些 feature，寫 IaC 或 GitOps 時可以先 assert 目標 controller 有哪些能力，減少上線後才發現功能沒生效的 debug 成本。
從別的 ingress 換過來的判斷點
工具比較不做「各有優缺點」的廢話，直接給判斷條件。
適合換到 Traefik 3.6 的情境：
- 現在跑 ingress-nginx，annotation 已經多到沒人敢動，想找一套宣告式、可組合、有型別的替代品。
- 有 SSO、feature flag、金絲雀灰度混在同一批 route 上，需要一次做完。
- Kubernetes CRD 或 file provider 是主要設定入口，不強依賴 Docker labels。
- 想把 Knative serverless 跟一般 API 收進同一個 proxy。
應該留在原方案的情境：
- 已經跑 Cilium 或 Istio，service mesh 的 policy engine 比 Traefik 的 middleware 完整，多層路由的價值有限。
- 主要用 Docker Compose + Traefik labels 部署，暫時等不到 Docker provider 支援。
- 需要 north-south 流量做深度 L7 policy（WAF、進階 rate limit、審計 log），Envoy 家族的能力還是比較全。
- 團隊已經深度用 Gateway API，且完全接受 Gateway API 自己的
parentRefs語意（HTTPRoute 綁定 Gateway）——那 Traefik 的 multi-layer routing 反而是概念重疊，不是簡化。
多層路由這個 feature 的甜蜜點是「Kubernetes 上有 20 到 200 條 route、幾個共用 middleware、想要設定檔看得懂」的中型場景。這正好是很多從雲端託管平臺搬回自建 Kubernetes 或 VPS 叢集的團隊會碰到的規模。
在臺灣 VPS 上跑 Traefik 的體感
Traefik 對機房位置沒偏好，但實務上有兩個地方會被延遲吃掉體驗。Let’s Encrypt HTTP-01 挑戰在啟動時要打到 CA 拿憑證，跨太平洋的來回會慢一點但不是問題；真正影響的是 Kubernetes API server 的延遲——Traefik 靠 informer watch CRD 變化，controller 跟 API server 距離越近，router 熱更新越即時。整套 control plane 都在同一個機房、同一段內網時，改一個 IngressRoute 到流量真的切過去可以做到秒級。
BGP 或 anycast 進來的流量在多節點 Traefik 前面通常還要一層 L4 load balancer，這部分 kube-vip、MetalLB 或機房自己的 anycast 網段都能接。臺灣機房內走的是本地內網延遲，比透過境外雲端 LB 繞回來省很多。
NCSE Network 的 VPS 服務位於臺灣是方電訊機房，配備 Intel Gold CPU 與 NVMe SSD，適合跑 Kubernetes control plane 這類對 disk latency 跟 CPU 單核效能敏感的工作負載；IP Transit 服務也可搭配 anycast 或 BGP 需求。要把 ingress 從老舊的 Nginx annotation 搬到 Traefik 3.6 的分層路由架構，可以到 NCSE Network 看看適合的方案。
