<p>According to the docs here <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-proto" rel="nofollow noreferrer">https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-proto</a>
Envoy proxy adds the Header <code>X-Forwarded-Proto</code> to the request, for some reason the header value is wrong; it set it as <code>http</code> although the incoming requests scheme is <code>https</code> which cause some problems in my application code since it depends on the correct value of this header.</p>
<p>Is this a bug in envoy? Can I prevent envoy from doing this?</p>

yakout
<p>As I mentioned in comments there is related <a href="https://github.com/istio/istio/issues/7964" rel="nofollow noreferrer">github issue</a> about that.</p>
<blockquote>
<p>Is there a way to prevent envoy from adding specific headers?</p>
</blockquote>
<p>There is istio dev @howardjohn <a href="https://github.com/istio/istio/issues/7964#issuecomment-679397836" rel="nofollow noreferrer">comment</a> about that</p>
<blockquote>
<p>We currently have two options:</p>
<ul>
<li><a href="https://istio.io/latest/docs/reference/config/networking/envoy-filter/" rel="nofollow noreferrer">EnvoyFilter</a></li>
<li><a href="https://preliminary.istio.io/latest/docs/ops/configuration/traffic-management/network-topologies/" rel="nofollow noreferrer">Alpha api</a></li>
</ul>
<p>There will not be a third; instead we will promote the alpha API.</p>
</blockquote>
<hr />
<p>So the first option would be envoy filter.</p>
<hr />
<p>There are 2 answers with that in above github issue.</p>
<p><a href="https://github.com/istio/istio/issues/7964#issuecomment-554241818" rel="nofollow noreferrer">Answer</a> provided by @jh-sz</p>
<blockquote>
<p>In general, use_remote_address should be set to true when Envoy is deployed as an edge node (aka a front proxy), whereas it may need to be set to false when Envoy is used as an internal service node in a mesh deployment.</p>
</blockquote>
<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: xff-trust-hops
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      istio: ingressgateway
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: ANY
      listener:
        filterChain:
          filter:
            name: &quot;envoy.http_connection_manager&quot;
    patch:
      operation: MERGE
      value:
        typed_config:
          &quot;@type&quot;: &quot;type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager&quot;
          use_remote_address: true
          xff_num_trusted_hops: 1
</code></pre>
<hr />
<p><strong>AND</strong></p>
<hr />
<p><a href="https://github.com/istio/istio/issues/7964#issuecomment-434466264" rel="nofollow noreferrer">Answer</a> provided by @vadimi</p>
<pre><code>apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: my-app-filter
spec:
  workloadLabels:
    app: my-app
  filters:
  - listenerMatch:
      portNumber: 5120
      listenerType: SIDECAR_INBOUND
    filterName: envoy.lua
    filterType: HTTP
    filterConfig:
      inlineCode: |
        function envoy_on_request(request_handle)
          request_handle:headers():replace(&quot;x-forwarded-proto&quot;, &quot;https&quot;)
        end
        function envoy_on_response(response_handle)
        end
</code></pre>
<hr />
<p>The second option would be Alpha api, this feature is actively in development and is considered pre-alpha.</p>
<hr />
<blockquote>
<p>Istio provides the ability to manage settings like <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for" rel="nofollow noreferrer">X-Forwarded-For</a> (XFF) and <a href="https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-client-cert" rel="nofollow noreferrer">X-Forwarded-Client-Cert</a> (XFCC), which are dependent on how the gateway workloads are deployed. This is currently an in-development feature. For more information on X-Forwarded-For, see the IETF’s <a href="https://www.rfc-editor.org/rfc/rfc7239" rel="nofollow noreferrer">RFC</a>.</p>
<p>You might choose to deploy Istio ingress gateways in various network topologies (e.g. behind Cloud Load Balancers, a self-managed Load Balancer or directly expose the Istio ingress gateway to the Internet). As such, these topologies require different ingress gateway configurations for transporting correct client attributes like IP addresses and certificates to the workloads running in the cluster.</p>
<p>Configuration of XFF and XFCC headers is managed via MeshConfig during Istio installation or by adding a pod annotation. Note that the Meshconfig configuration is a global setting for all gateway workloads, while pod annotations override the global setting on a per-workload basis.</p>
</blockquote>
