Observe a Proxy's Forwarded Request at Its Destination
Choose the correct observation point for headers added or changed after the client sends an HTTP request.
A client prepares an HTTP request, and a forward proxy can change that message before sending it onward. The destination is where the forwarded version becomes observable.
| Observation point | Message available there |
|---|---|
| Client's request object | The request prepared for the first hop |
| Origin's request log or echo handler | The request received after forwarding |
| Client's response-header collection | The response received on the return path |
For a controlled check, use an endpoint you operate that records or returns the received request headers. Give the request an identifiable marker so the origin record can be associated with the particular client operation.
In a WebClient-based application, ResponseHeaders describes the returned response. It is not a recording of the proxy's request to the destination. A server can choose to echo request information in its response body, but that is application behavior.
If the path contains several intermediaries, the destination sees their combined forwarding effects. The presence of a header alone does not attribute a change to one particular hop. For custom API fields, the forwarding and Connection-field rules explain when alteration is expected.
An ordinary HTTPS CONNECT tunnel adds another boundary: the inner HTTP request is encrypted between the client and website. A relay proxy cannot edit those encrypted headers. Headers on the CONNECT exchange belong to that separate exchange, while a managed TLS inspection proxy has a different role.