Forward vs reverse proxies, what they change (TLS, headers, timeouts, buffering), X-Forwarded-* headers and the ForwardedHeaders middleware, outbound proxy settings, and spoofing risks.
CONNECT. HttpClient picks it up from system settings or HTTP_PROXY/HTTPS_PROXY/NO_PROXY.Behind a reverse proxy, the app sees the proxy's IP and often plain http. The proxy passes the originals in X-Forwarded-For and X-Forwarded-Proto, but ASP.NET Core only applies them via the ForwardedHeaders middleware, and by default only trusts proxies on loopback. So UseHttpsRedirection sees http, redirects to https, the proxy forwards as http again: a loop.
Fix: UseForwardedHeaders first, configured with the proxy's IPs or network in KnownProxies/known networks. Do not trust all sources, or clients can spoof their IP and scheme.
Forward proxy (client side)
app ──► corp proxy ──► internet APIs
(egress control, logging, maybe TLS inspection)
Reverse proxy (server side)
users ──► [CDN/WAF] ──► reverse proxy / ingress ──► app instances
(TLS termination, routing, LB, headers)
| Forward proxy | Reverse proxy | |
|---|---|---|
| Acts for | Clients | Servers |
| Who configures it | Client / OS / environment variables | Server operators |
| Typical products | Squid, Zscaler, corporate proxies | nginx, Envoy, HAProxy, YARP, Azure App Gateway, AWS ALB, ingress controllers |
| Purpose | Egress control, caching, anonymity, inspection | TLS offload, routing, load balancing, caching, WAF, compression |
| Aspect | Without ForwardedHeaders | With it configured |
|---|---|---|
Connection.RemoteIpAddress |
Proxy IP (e.g. 10.240.0.4) | Client IP from X-Forwarded-For |
Request.Scheme |
http |
https from X-Forwarded-Proto |
Request.Host |
Internal host | Original host (if X-Forwarded-Host enabled and allowed) |
Wrong values break HTTPS redirection, absolute URLs and OAuth/OIDC redirect_uri (identity provider rejects http://), rate limiting by IP, audit logs and geo rules.
After moving an app from IIS to AKS behind ingress-nginx, logins failed with "redirect_uri mismatch" (it was sending http://...), and some pages looped on HTTPS redirect. Logs showed every request from 10.244.1.12, the ingress pod. We added UseForwardedHeaders as the first middleware with ForwardedHeaders.XForwardedFor | XForwardedProto and added the ingress pod CIDR to the known networks. Logins worked, logs showed real client IPs, and the rate limiter started limiting real clients instead of the ingress.
Checks understanding of proxies in real deployments and a common class of bugs after moving behind a load balancer or ingress.
Green flags
Red flags
client 203.0.113.9 ─► CDN 198.51.100.7 ─► ingress 10.244.1.12 ─► app
X-Forwarded-For: 203.0.113.9, 198.51.100.7
Remote address seen by app: 10.244.1.12
The middleware walks the list from the right, accepting each hop only if the previous one is a known proxy, up to ForwardLimit (default 1). With a CDN plus ingress you need ForwardLimit = 2 and both trusted.
Any client can send X-Forwarded-For: 1.2.3.4. If you trust all sources, an attacker can bypass IP allow-lists and rate limits, and fake HTTPS. That is why KnownProxies/known networks default to loopback only.
ASPNETCORE_FORWARDEDHEADERS_ENABLED=true turns the middleware on for XForwardedFor and XForwardedProto and clears the known proxies and networks so it trusts any source. It is a convenience for container platforms where only the proxy can reach the app; use it only when network rules guarantee that.
UseForwardedHeaders() must run before UseHttpsRedirection, UseHsts, authentication, rate limiting, logging enrichment and anything that reads scheme, host or IP.
| Effect | Symptom | Fix |
|---|---|---|
Proxy timeout (e.g. nginx proxy_read_timeout 60 s) |
504 on long requests | Raise for specific routes or make the work async |
Request body limit (nginx client_max_body_size 1 MB default) |
413 on uploads | Raise on the proxy and in Kestrel |
| Response buffering | Server-sent events or streaming arrive all at once | Disable buffering for those routes |
| Header size limits | 400/502 with big cookies or tokens | Raise limits or shrink headers |
| HTTP version | gRPC fails through an HTTP/1.1-only hop | Enable HTTP/2 end to end |
HttpClient.DefaultProxy reads system settings (Windows) and HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY environment variables.NO_PROXY for internal hosts sends internal traffic through the corporate proxy (slow, or blocked).YARP (Yet Another Reverse Proxy) is a .NET library for building reverse proxies in ASP.NET Core: routes and clusters from configuration, load balancing, health checks, header transforms (it adds X-Forwarded-* by default), and session affinity. Useful for BFFs, gateways and gradual migrations (strangler fig).
RemoteIpAddress and Scheme before and after enabling forwarded headers.curl -H "X-Forwarded-For: 1.2.3.4" directly to the app with "trust all" vs known proxies only.using Microsoft.AspNetCore.HttpOverrides;
using System.Net;
var builder = WebApplication.CreateBuilder(args);
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.ForwardLimit = 2; // CDN + ingress
options.KnownProxies.Clear();
options.KnownProxies.Add(IPAddress.Parse("10.240.0.4")); // ingress / app gateway private IP
// or trust a whole subnet the proxies live in, via the options' known networks list
});
var app = builder.Build();
app.UseForwardedHeaders(); // FIRST: before HTTPS redirection, auth, rate limiting, logging
app.UseHsts();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapGet("/whoami", (HttpContext ctx) => new
{
ip = ctx.Connection.RemoteIpAddress?.ToString(),
scheme = ctx.Request.Scheme,
host = ctx.Request.Host.Value
});
app.Run();
// Minimal YARP reverse proxy (package Yarp.ReverseProxy)
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy().LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));
var app = builder.Build();
app.MapReverseProxy();
app.Run();
# Outbound via a corporate forward proxy, but not for internal hosts
export HTTPS_PROXY=http://proxy.corp:3128
export NO_PROXY=localhost,127.0.0.1,.svc.cluster.local,.corp.internal
http, which breaks HTTPS redirection, OAuth redirect URIs, rate limiting and audit logs. Instead: call UseForwardedHeaders() first, configured for your proxies.UseForwardedHeaders after other middleware. Earlier middleware has already used the wrong scheme or IP. Instead: put it at the top of the pipeline.HTTPS_PROXY without NO_PROXY. Internal calls go through the corporate proxy and fail or slow down. Instead: list internal domains and cluster suffixes in NO_PROXY.A reverse proxy changes the request the app sees, so the app must be told which hops to trust. I think of X-Forwarded-* as claims that are only valid when they come from a known proxy; getting that trust boundary right is a security decision, not just a configuration fix.
Operationally, every proxy hop adds its own timeouts, size limits, buffering and HTTP version, and many "app" incidents are really proxy defaults. I keep proxy configuration in the same repository as the app, document each hop (CDN, WAF, gateway, ingress), and test through the real chain in staging. For .NET-centric gateways and BFFs, YARP gives a programmable reverse proxy without leaving the stack.
A load balancer spreads traffic across healthy instances.
Health checks remove unhealthy instances (in Kubernetes: readiness for traffic, liveness for restarts). Algorithms: round robin, least connections/requests, hashing. Sticky sessions pin a user to one instance, which hurts scaling and failover. Connection draining stops new traffic to an instance before shutdown so in-flight requests finish.
gRPC uses long-lived HTTP/2 connections, so an L4 balancer balances connections, not calls: one client connection carries all its calls to one pod. Use L7 balancing (mesh/Envoy) or client-side load balancing.
HTTPS is HTTP inside TLS. TLS gives confidentiality (encryption), integrity (tamper detection) and server authentication (certificates).
TLS 1.3 handshake (one round trip): the client sends supported ciphers, a key share, SNI (hostname) and ALPN (h2); the server replies with its key share, certificate chain and a signature proving it owns the private key. Both derive session keys via ECDHE (forward secrecy).
The client validates: chain to a trusted root, not expired, hostname matches the SAN, and optionally revocation.
For "remote certificate is invalid": read the SslPolicyErrors / chain status, inspect with openssl s_client -showcerts, then fix the real cause (expired cert, missing intermediate, wrong hostname, or a private/corporate root CA not trusted in the container). Never return true from ServerCertificateCustomValidationCallback in production.
An IP address identifies a network interface so packets can be routed to it.
192.168.1.10. About 4.3 billion addresses, which ran out, so most networks use private ranges behind NAT.2001:db8::1. Enough addresses for everything to be globally routable.10.0.1.0/24 means the first 24 bits are the network, leaving 8 bits (256 addresses) for hosts.10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. Loopback: 127.0.0.1, ::1.How to tell it (STAR)
**S:** After moving our [customer portal] to Kubernetes, logins failed and the rate limiter blocked everyone together. **T:** I had to fix it without weakening security. **A:** The app saw every request as `http` from the ingress IP because forwarded headers were not being applied. I added the ForwardedHeaders middleware first in the pipeline and trusted only the ingress subnet, so spoofed headers from elsewhere are ignored. **R:** Logins worked again, logs showed real client IPs, and rate limiting applied per user as intended.
Last updated 23 Oct 2026.