HTTP 標頭操作

HTTP 連線管理器會在解碼期間 (接收請求時) 以及編碼期間 (傳送回應時) 操作數個 HTTP 標頭。

:scheme

Envoy 在處理請求時將始終設定 :scheme 標頭。它應始終可供過濾器使用，且應針對 HTTP/2 和 HTTP/3 轉發至上游，其中 x-forwarded-proto 將針對 HTTP/1.1 傳送。

對於 HTTP/2 和 HTTP/3，傳入的 :scheme 標頭是受信任的，並會透過上游傳播。對於 HTTP/1，:scheme 標頭將會設定為 1) 從絕對 URL (如果存在且有效)。無效的 (非「http」或「https」) 配置，或在未加密連線上使用 https 配置，將導致 Envoy 拒絕請求。這是 Envoy 執行的唯一配置驗證，因為它避免了邊緣 Envoy 的 HTTP/1.1 特定權限提升攻擊 [1]，該攻擊對於 HTTP/2 及更高版本沒有可比的向量 [2]。2) 從清理後的 x-forwarded-proto 標頭值 (從受信任的下游到有效的 x-forwarded-proto，否則根據下游加密等級)。

此預設行為可以透過 scheme_header_transformation 組態選項覆寫。

Envoy 將在想要 URI 配置時，在 x-forwarded-proto 上使用 :scheme 標頭，例如根據 :scheme 標頭而不是 X-Forwarded-Proto 從快取提供內容，或根據原始 URI 的配置設定重新導向的配置。如需更多詳細資訊，請參閱 為什麼 Envoy 會在 X-Forwarded-Proto 而非 :scheme 上運作，反之亦然？。

:path

:path 標頭是 Envoy 使用 HTTP 請求路徑值填入的虛擬標頭。例如，GET /docs/thing HTTP/1.1 形式的 HTTP 請求將具有 /docs/thing 的 :path 值。

:method

:method 標頭是 Envoy 使用 HTTP 請求方法值填入的虛擬標頭。例如，GET /docs/thing HTTP/1.1 形式的 HTTP 請求將具有 GET 的 :method 值。值為大寫，例如 GET、PUT、POST 和 DELETE。HTTP 方法 <https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods> 中描述了其他可能的值。

user-agent

如果啟用 add_user_agent 選項，連線管理器可能會在解碼期間設定 user-agent 標頭。只有在尚未設定標頭時才會修改標頭。如果連線管理器確實設定了標頭，則值由 --service-cluster 命令列選項決定。

server

server 標頭將在編碼期間設定為 server_name 選項中的值。

referer

referer 標頭將在解碼期間清理。將移除多個 URL、包含片段元件的無效相對 URL，以及包含 userinfo 或片段元件的有效絕對 URL。

x-client-trace-id

如果外部用戶端設定此標頭，Envoy 將會將提供的追蹤 ID 與內部產生的 x-request-id 聯結。x-client-trace-id 需要全域唯一，建議產生 uuid4。如果設定此標頭，它具有與 x-envoy-force-trace 類似的效果。請參閱 tracing.client_enabled 執行階段組態設定。

x-envoy-downstream-service-cluster

內部服務通常想要知道哪個服務正在呼叫它們。此標頭會從外部請求中清除，但對於內部請求，將包含呼叫者的服務叢集。請注意，在目前的實作中，這應視為提示，因為它由呼叫者設定，任何內部實體都可能會輕易地欺騙它。未來，Envoy 將支援相互驗證 TLS 網狀網路，這將使此標頭完全安全。與 user-agent 一樣，值由 --service-cluster 命令列選項決定。為了啟用此功能，您需要將 user_agent 選項設定為 true。

x-envoy-downstream-service-node

內部服務可能想要知道下游節點請求來自何處。此標頭與 x-envoy-downstream-service-cluster 非常相似，只是值取自 --service-node 選項。

x-envoy-external-address

在許多情況下，服務會希望根據來源用戶端的 IP 位址執行分析。根據關於 XFF 的冗長討論，這可能會變得相當複雜，因此 Envoy 通過將 x-envoy-external-address 設定為受信任的用戶端位址（如果請求來自外部用戶端）來簡化此過程。對於內部請求，x-envoy-external-address 不會設定或覆寫。為了進行分析，此標頭可以在內部服務之間安全地轉發，而無需處理 XFF 的複雜性。

x-envoy-force-trace

如果內部請求設定了此標頭，Envoy 將修改產生的 x-request-id，以強制收集追蹤資料。這也會強制在回應標頭中傳回 x-request-id。如果此請求 ID 隨後傳播到其他主機，也會在這些主機上收集追蹤資料，這將為整個請求流程提供一致的追蹤。請參閱 tracing.global_enabled 和 tracing.random_sampling 執行階段設定。

x-envoy-internal

在許多情況下，服務會想知道請求是否來自內部來源。Envoy 使用 XFF 來判斷這一點，然後會將標頭值設定為 true。

這是一種方便的做法，可以避免必須剖析和理解 XFF。

x-envoy-original-dst-host

此標頭用於在使用 原始目的地 負載平衡策略時覆寫目的地位址。

除非通過 use_http_header 啟用使用，否則會忽略此標頭。

x-forwarded-client-cert

x-forwarded-client-cert (XFCC) 是一個代理標頭，指示請求從用戶端到伺服器的過程中，經過的部分或全部用戶端或代理的憑證資訊。代理可能會選擇在代理請求之前清理/附加/轉發 XFCC 標頭。

XFCC 標頭值是一個以逗號 (",") 分隔的字串。每個子字串都是一個 XFCC 元素，其中包含單個代理新增的資訊。代理可以將目前的用戶端憑證資訊作為一個 XFCC 元素，附加到請求的 XFCC 標頭末尾，並以逗號分隔。

每個 XFCC 元素都是一個以分號 (";") 分隔的字串。每個子字串都是一個鍵值對，以等號 ("=") 符號分組在一起。鍵不區分大小寫，值區分大小寫。如果值中出現 ",", ";" 或 "="，則該值應以雙引號括起來。值中的雙引號應由反斜線雙引號 (\") 取代。

支援下列鍵

  1. By 目前代理憑證的主體替代名稱 (URI 類型)。目前的代理憑證可能包含多個 URI 類型的主體替代名稱，每個都將是一個單獨的鍵值對。

  2. Hash 目前用戶端憑證的 SHA 256 摘要。

  3. Cert URL 編碼 PEM 格式的完整用戶端憑證。

  4. Chain URL 編碼 PEM 格式的完整用戶端憑證鏈 (包含葉節點憑證)。

  5. Subject 目前用戶端憑證的主體欄位。該值始終以雙引號括起來。

  6. URI 目前用戶端憑證的 URI 類型主體替代名稱欄位。一個用戶端憑證可能包含多個 URI 類型的主體替代名稱，每個都將是一個單獨的鍵值對。

  7. DNS 目前用戶端憑證的 DNS 類型主體替代名稱欄位。一個用戶端憑證可能包含多個 DNS 類型的主體替代名稱，每個都將是一個單獨的鍵值對。

用戶端憑證可能包含多種主體替代名稱類型。有關不同主體替代名稱類型的詳細資訊，請參考 RFC 2459。

以下是 XFCC 標頭的一些範例

  1. 對於只有 URI 類型主體替代名稱的一個用戶端憑證： x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client";URI=http://testclient.lyft.com

  2. 對於只有 URI 類型主體替代名稱的兩個用戶端憑證： x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;URI=http://testclient.lyft.com,By=http://backend.lyft.com;Hash=9ba61d6425303443c0748a02dd8de688468ed33be74eee6556d90c0149c1309e;URI=http://frontend.lyft.com

  3. 對於具有 URI 類型和 DNS 類型主體替代名稱的一個用戶端憑證： x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client";URI=http://testclient.lyft.com;DNS=lyft.com;DNS=www.lyft.com

Envoy 如何處理 XFCC 由 forward_client_cert_details 和 set_current_client_cert_details HTTP 連線管理員選項指定。如果未設定 forward_client_cert_details，則預設會清理 XFCC 標頭。

x-forwarded-for

x-forwarded-for (XFF) 是一個標準代理標頭，指示請求從用戶端到伺服器的過程中經過的 IP 位址。符合規範的代理會在代理請求之前將最接近用戶端的 IP 位址 附加 到 XFF 清單。以下是一些 XFF 的範例

  1. x-forwarded-for: 50.0.0.1 (單一用戶端)

  2. x-forwarded-for: 50.0.0.1, 40.0.0.1 (外部代理躍點)

  3. x-forwarded-for: 50.0.0.1, 10.0.0.1 (內部代理躍點)

只有在 use_remote_address HTTP 連線管理員選項設定為 true 且 skip_xff_append 設定為 false 時，Envoy 才會附加到 XFF。這表示如果 use_remote_address 為 false (預設值) 或 skip_xff_append 為 true，則連線管理員會在透明模式下運作，也就是不會修改 XFF。

注意

一般而言，當 Envoy 部署為邊緣節點 (也稱為前端代理) 時，應將 use_remote_address 設定為 true，而在網格部署中將 Envoy 用作內部服務節點時，可能需要將其設定為 false。

use_remote_address 的值控制 Envoy 如何判斷受信任的用戶端位址。假設一個 HTTP 請求已通過一系列零個或多個代理到達 Envoy，則受信任的用戶端位址是已知準確的最早來源 IP 位址。與 Envoy 連線的直接下游節點的來源 IP 位址是受信任的。XFF 有時可以信任。惡意用戶端可以偽造 XFF，但如果 XFF 中的最後一個位址是由受信任的代理放置在那裡的，則可以信任它。

或者，Envoy 支援 擴充功能，以判斷受信任的用戶端位址或原始 IP 位址。

注意

此類擴充功能的使用不能與 use_remote_address 或 xff_num_trusted_hops 混用。

Envoy 用於判斷受信任的用戶端位址的預設規則 (在將任何內容附加到 XFF 之前) 為

  • 如果 use_remote_address 為 false 且請求中存在至少一個 IP 位址的 XFF，則受信任的用戶端位址是 XFF 中最後一個 (最右邊) 的 IP 位址。

  • 否則，受信任的用戶端位址是與 Envoy 連線的直接下游節點的來源 IP 位址。

在邊緣 Envoy 執行個體前面有一個或多個受信任代理的環境中，可以使用 xff_num_trusted_hops 組態選項來信任來自 XFF 的其他位址

  • 如果 use_remote_address 為 false 且 xff_num_trusted_hops 設定為大於零的值 N，則受信任的用戶端位址是 XFF 右邊算起第 (N+1) 個位址。(如果 XFF 包含少於 N+1 個位址，Envoy 會退回使用直接下游連線的來源位址作為受信任的用戶端位址。)

  • 如果 use_remote_address 為 true 且 xff_num_trusted_hops 設定為大於零的值 N，則受信任的用戶端位址是 XFF 右邊算起第 N 個位址。(如果 XFF 包含少於 N 個位址，Envoy 會退回使用直接下游連線的來源位址作為受信任的用戶端位址。)

注意

如果信任的客戶端位址應從已知的 CIDR 清單中判斷，請改用 xff 原始 IP 偵測選項。

  • 如果遠端位址包含在 xff_trusted_cidrs 中的一個條目中，且最後一個（最右邊）的條目也包含在 xff_trusted_cidrs 中的一個條目中，則信任的客戶端位址為 XFF 中的倒數第二個 IP 位址。

  • 如果 XFF 中的所有條目都包含在 xff_trusted_cidrs 中的一個條目中，則信任的客戶端位址為 XFF 中的第一個（最左邊）IP 位址。

Envoy 使用信任的客戶端位址內容來判斷請求是來自外部還是內部。這會影響是否設定 x-envoy-internal 標頭。

範例 1：Envoy 作為邊緣代理，前面沒有信任的代理
設定
use_remote_address = true
xff_num_trusted_hops = 0
請求詳細資訊
下游 IP 位址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1”
結果
信任的客戶端位址 = 192.0.2.5（忽略 XFF）
X-Envoy-External-Address 設定為 192.0.2.5
XFF 變更為 “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）
範例 2：Envoy 作為內部代理，前面有範例 1 中的 Envoy 邊緣代理
設定
use_remote_address = false
xff_num_trusted_hops = 0
請求詳細資訊
下游 IP 位址 = 10.11.12.13（Envoy 邊緣代理的位址）
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
結果
信任的客戶端位址 = 192.0.2.5（信任 XFF 中的最後一個位址）
X-Envoy-External-Address 不會修改
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）
範例 3：Envoy 作為邊緣代理，前面有兩個信任的外部代理
設定
use_remote_address = true
xff_num_trusted_hops = 2
請求詳細資訊
下游 IP 位址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1”
結果
信任的客戶端位址 = 203.0.113.10（信任 XFF 中倒數第二個位址）
X-Envoy-External-Address 設定為 203.0.113.10
XFF 變更為 “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）
範例 4：Envoy 作為內部代理，前面有範例 3 中的邊緣代理
設定
use_remote_address = false
xff_num_trusted_hops = 2
請求詳細資訊
下游 IP 位址 = 10.11.12.13（Envoy 邊緣代理的位址）
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
結果
信任的客戶端位址 = 203.0.113.10
X-Envoy-External-Address 不會修改
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）
範例 5：Envoy 作為內部代理，接收來自內部客戶端的請求
設定
use_remote_address = false
xff_num_trusted_hops = 0
請求詳細資訊
下游 IP 位址 = 10.20.30.40（內部客戶端的位址）
XFF 不存在
結果
信任的客戶端位址 = 10.20.30.40
X-Envoy-External-Address 維持未設定
X-Envoy-Internal 設定為 “false”
範例 6：範例 5 中的內部 Envoy，接收由另一個 Envoy 代理的請求
設定
use_remote_address = false
xff_num_trusted_hops = 0
請求詳細資訊
下游 IP 位址 = 10.20.30.50（代理到此實例的 Envoy 實例的位址）
XFF = “10.20.30.40”
結果
信任的客戶端位址 = 10.20.30.40
X-Envoy-External-Address 維持未設定
X-Envoy-Internal 設定為 “true”
範例 7：Envoy 作為邊緣代理，具有一個信任的 CIDR
設定
use_remote_address = false
xff_trusted_cidrs = 192.0.2.0/24
請求詳細資訊
下游 IP 位址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 192.0.2.1”
結果
信任的客戶端位址 = 192.0.2.1
X-Envoy-External-Address 設定為 192.0.2.1
XFF 變更為 “203.0.113.128, 203.0.113.10, 192.0.2.1, 192.0.2.5”
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）
範例 8：Envoy 作為邊緣代理，具有兩個信任的 CIDR
設定
use_remote_address = false
xff_trusted_cidrs = 192.0.2.0/24, 198.51.100.0/24
請求詳細資訊
下游 IP 位址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 198.51.100.1”
結果
信任的客戶端位址 = 203.0.113.10
X-Envoy-External-Address 設定為 203.0.113.10
XFF 變更為 “203.0.113.128, 203.0.113.10, 198.51.100.1, 192.0.2.5”
X-Envoy-Internal 被移除（如果它存在於傳入的請求中）

關於 XFF 的一些非常重要的注意事項

  1. 如果 use_remote_address 設定為 true，Envoy 會將 x-envoy-external-address 標頭設定為信任的客戶端位址。

  1. XFF 是 Envoy 用來判斷請求是來自內部還是外部的依據。如果 use_remote_address 設定為 true，則當且僅當請求不包含 XFF 且與 Envoy 連線的直接下游節點具有內部 (RFC1918 或 RFC4193) 來源位址時，請求才會被視為內部請求。如果 use_remote_address 為 false，則當且僅當 XFF 包含單個 RFC1918 或 RFC4193 位址時，請求才會被視為內部請求。

    • 注意：如果內部服務將外部請求代理到另一個內部服務，並包含原始的 XFF 標頭，如果設定了 use_remote_address，Envoy 將在出口時附加到它。這將導致另一方認為請求是外部的。一般來說，如果正在轉發 XFF，這就是預期的行為。如果不是預期的行為，請不要轉發 XFF，而是轉發 x-envoy-internal。

    • 注意：如果將內部服務呼叫轉發到另一個內部服務（保留 XFF），Envoy 不會將其視為內部呼叫。由於簡化了 XFF 的解析方式以判斷請求是否為內部請求，這是一個已知的「錯誤」。在這種情況下，請不要轉發 XFF，並允許 Envoy 使用單個內部來源 IP 產生一個新的 XFF。

x-forwarded-host

x-forwarded-host 標頭是一個事實上的標準代理標頭，它表示用戶端在 :authority （HTTP1 中的 host）標頭中請求的原始主機。如果 :authority 標頭已修改，符合規範的代理會將 :authority 標頭的原始值附加到 x-forwarded-host。

如果使用主機重寫選項（host_rewrite_literal、auto_host_rewrite、host_rewrite_header 或 host_rewrite_path_regex 其中之一），Envoy 會更新 :authority 標頭，並且如果設定了 append_x_forwarded_host，則會將其原始值附加到 x-forwarded-host。

x-forwarded-port

通常，x-forwarded-port 標頭會與 x-forwarded-proto 標頭一起使用，以使服務知道連線的原始目標埠，也就是 Envoy 端上的監聽器埠。

如果 append_x_forwarded_port 設定為 true 且標頭尚未設定，Envoy 將會附加 x-forwarded-port 標頭。

只有在 xff_num_trusted_hops 非零時，才會信任下游 x-forwarded-port 標頭。如果 xff_num_trusted_hops 為零，則下游 x-forwarded-port 標頭將會被覆寫。

x-forwarded-proto

常見的情況是服務想要知道由前端/邊緣 Envoy 終止的連線的原始協定（HTTP 或 HTTPS）。x-forwarded-proto 包含此資訊。它將設定為 http 或 https。

只有在 xff_num_trusted_hops 非零時，才會信任下游 x-forwarded-proto 標頭。如果 xff_num_trusted_hops 為零，則下游 x-forwarded-proto 標頭和 :scheme 標頭將根據下游連線是否為 TLS 而設定為 http 或 https。

如果透過 scheme_header_transformation 設定選項變更了協定，x-forwarded-proto 也會一併更新。

Envoy 會優先使用 x-forwarded-proto 而不是 :scheme，當需要底層加密時，例如根據 x-forwarded-proto 清除預設埠。如需更多詳細資訊，請參閱 為什麼 Envoy 使用 X-Forwarded-Proto 而不是 :scheme，反之亦然？。

x-envoy-local-overloaded

如果由於 過載管理器 而捨棄了請求，且 設定選項 設定為 true，Envoy 將會在下游回應中設定此標頭。

x-request-id

Envoy 使用 x-request-id 標頭來唯一識別請求，以及執行穩定的存取記錄和追蹤。Envoy 將為所有外部來源請求產生一個 x-request-id 標頭（標頭已清理）。它也將為尚未擁有 x-request-id 標頭的內部請求產生一個 x-request-id 標頭。這表示可以在用戶端應用程式之間傳播 x-request-id，以便在整個網格中具有穩定的 ID。由於 Envoy 的進程外架構，Envoy 本身無法自動轉發標頭。這是少數幾個需要精簡用戶端程式庫來執行此任務的領域之一。如何執行此操作超出了本文檔的範圍。如果 x-request-id 在所有主機之間傳播，則可以使用以下功能

有關更多資訊，請參閱關於 上下文傳播 的架構概述。

x-ot-span-context

當與 LightStep 追蹤器一起使用時，Envoy 會使用 x-ot-span-context HTTP 標頭在追蹤跨度之間建立適當的父子關係。例如，出口跨度是入口跨度的子跨度（如果存在入口跨度）。Envoy 在入口請求上注入 x-ot-span-context 標頭，並將其轉發到本地服務。Envoy 依靠應用程式在向上游的出站呼叫上傳播 x-ot-span-context。有關追蹤的更多資訊，請參閱此處。

x-b3-traceid

Envoy 中的 Zipkin 追蹤器會使用 x-b3-traceid HTTP 標頭。TraceId 長度為 64 位元，表示追蹤的整體 ID。追蹤中的每個跨度都共用此 ID。有關 zipkin 追蹤的更多資訊，請參閱此處。

x-b3-spanid

Envoy 中的 Zipkin 追蹤器會使用 x-b3-spanid HTTP 標頭。SpanId 長度為 64 位元，表示目前操作在追蹤樹中的位置。該值不應被解釋：它可能衍生自或不衍生自 TraceId 的值。有關 zipkin 追蹤的更多資訊，請參閱此處。

x-b3-parentspanid

Envoy 中的 Zipkin 追蹤器會使用 x-b3-parentspanid HTTP 標頭。ParentSpanId 長度為 64 位元，表示父操作在追蹤樹中的位置。當跨度是追蹤樹的根時，不存在 ParentSpanId。有關 zipkin 追蹤的更多資訊，請參閱此處。

x-b3-sampled

Envoy 中的 Zipkin 追蹤器會使用 x-b3-sampled HTTP 標頭。當 Sampled 旗標未指定或設定為 1 時，跨度將會回報給追蹤系統。一旦 Sampled 設定為 0 或 1，則應始終將相同的值向下游傳送。有關 zipkin 追蹤的更多資訊，請參閱此處。

x-b3-flags

Envoy 中的 Zipkin 追蹤器會使用 x-b3-flags HTTP 標頭。編碼一個或多個選項。例如，Debug 編碼為 X-B3-Flags: 1。有關 zipkin 追蹤的更多資訊，請參閱此處。

b3

Envoy 中的 Zipkin 追蹤器會使用 b3 HTTP 標頭。這是一種更壓縮的標頭格式。有關 zipkin 追蹤的更多資訊，請參閱此處。

x-datadog-trace-id

Envoy 中的 Datadog 追蹤器會使用 x-datadog-trace-id HTTP 標頭。64 位元值表示整體追蹤的 ID，用於關聯跨度。

x-datadog-parent-id

Envoy 中的 Datadog 追蹤器會使用 x-datadog-parent-id HTTP 標頭。64 位元值唯一識別追蹤內的跨度，用於在跨度之間建立父子關係。

x-datadog-sampling-priority

Envoy 中的 Datadog 追蹤器會使用 x-datadog-sampling-priority HTTP 標頭。整數值表示已為此追蹤做出的取樣決策。值 0 表示不應收集追蹤，而值 1 則表示應取樣和回報跨度。

sw8

Envoy 中的 SkyWalking 追蹤器會使用 sw8 HTTP 標頭。它包含 SkyWalking 追蹤器的金鑰追蹤上下文，用於建立下游和 Envoy 的追蹤跨度之間的關係。有關 SkyWalking 追蹤的更多資訊，請參閱此處。

x-amzn-trace-id

Envoy 中的 AWS X-Ray 追蹤器會使用 x-amzn-trace-id HTTP 標頭。追蹤 ID、父 ID 和取樣決策會新增至追蹤標頭中的 HTTP 請求。有關 AWS X-Ray 追蹤的更多資訊，請參閱此處。

自訂請求/回應標頭

可以將自訂請求/回應標頭新增至加權叢集、路由、虛擬主機和/或全域路由組態層級的請求/回應。請參閱 v3 API 文件。

不得透過此機制修改帶有 : 前綴的虛擬標頭或 Host: 標頭。:path 和 :authority 標頭可以透過諸如 prefix_rewrite、regex_rewrite 和 host_rewrite 等機制來修改。

標頭會依以下順序附加至請求/回應：加權叢集層級標頭、路由層級標頭、虛擬主機層級標頭，最後是全域層級標頭。

Envoy 支援將動態值新增至請求和回應標頭。百分比符號 (%) 用於分隔變數名稱。

注意

如果請求/回應標頭中需要使用字面百分比符號 (%)，則必須將其重複寫兩次以進行逸出。例如，若要發出值為 100% 的標頭，Envoy 組態中的自訂標頭值必須為 100%%。

所有用於存取日誌記錄的 HTTP 命令運算符都可以在自訂請求/回應標頭中指定。但是，根據特定命令運算符的使用位置，運算符所需的內容可能不可用，並且產生的輸出為空字串。例如，以下組態使用 %RESPONSE_CODE% 運算符，以使用來自回應的程式碼修改請求標頭。輸出為空字串，因為請求標頭是在請求向上游傳送之前修改的，並且尚未收到回應。

header_formatters.yaml
1          route_config:
2            name: local_route
3            request_headers_to_add:
4            - header:
5                key: "response-code"
6                value: "%RESPONSE_CODE%"

注意

仍然支援以下舊版標頭格式化程式，但將來會被棄用。可以使用指示的替代項來存取等效資訊。

%DYNAMIC_METADATA(["namespace", "key", ...])%

使用請求中可用的動態中繼資料（例如：由 header-to-metadata 篩選器等篩選器新增）填入標頭。

這適用於請求和回應標頭。

請改用 %DYNAMIC_METADATA(namespace:key:…):Z%。

%UPSTREAM_METADATA(["namespace", "key", ...])%

從路由器選擇的上游主機中，使用EDS 端點元數據來填充標頭。元數據可以從任何命名空間中選取。一般來說，元數據值可以是字串、數字、布林值、列表、巢狀結構或空值。上游元數據值可以透過指定多個鍵，從巢狀結構中選取。否則，僅支援字串、布林值和數值類型。如果找不到命名空間或鍵，或者選取的值是不支援的類型，則不會發出標頭。命名空間和鍵會被指定為字串的 JSON 陣列。最後，參數中的百分比符號 **不需要** 透過重複它們來轉義。

上游元數據無法新增至請求標頭，因為在產生自訂請求標頭時，尚未選取上游主機。

請改用 %UPSTREAM_METADATA(namespace:key:…):Z%。

%PER_REQUEST_STATE(reverse.dns.data.name)%

使用在串流資訊 filterState() 物件上設定的值來填充標頭。為了能在自訂請求/回應標頭中使用，這些值必須是 Envoy::Router::StringAccessor 類型。這些值應該以標準反向 DNS 樣式命名，以識別建立該值的組織，並以該資料的唯一名稱結尾。

請改用 %FILTER_STATE(reverse.dns.data.name:PLAIN):Z%。