Networking, Proxies & Service Mesh

Declare the store once with proxy_cache_path in the http context, then switch it on with proxy_cache <zone> in the proxying server or location. Confirm hits by logging $upstream_cache_status, which reports HIT, MISS, BYPASS, EXPIRED, STALE, UPDATING or REVALIDATED.

An nginx configuration is a tree of nested contexts — main, events, http, server, location — and each nested level inherits the directives of the level above it unless that level sets its own value for the same directive.

Set Host, X-Forwarded-For and X-Forwarded-Proto with proxy_set_header. Nginx defaults Host to $proxy_host, the proxied server's name, and sends no forwarded headers at all, so the app sees the proxy's IP and assumes plain HTTP.

A permanent MISS means nginx is looking but never storing. Check the request method (GET and HEAD only by default), then the upstream headers — Set-Cookie, Cache-Control no-store/no-cache/private/max-age=0, or a past Expires all block storage — then whether proxy_cache_valid covers that status code.

limit_req meters request arrival rate, so a client that opens one request and keeps it open forever never trips it. limit_conn caps concurrent in-flight connections per key, which is the resource slow downloads and slowloris-style clients actually consume.

With [L] alone the rewrite is internal: Apache serves the new path itself and the client never learns anything changed. With [R=301,L] Apache sends a redirect response carrying a Location header, so the browser issues a second request and its address bar updates.

Apache httpd looks for an .htaccess file in every directory along the path to the requested file, on every request, and re-parses each one it finds. AllowOverride None removes that lookup entirely; any other value enables it.

mpm_prefork dedicates one single-threaded process per connection; mpm_worker runs many threads inside a few processes; mpm_event is worker plus a listener thread that holds idle keep-alive connections so no worker thread is parked on them.

MaxRequestWorkers is the total worker threads across all children, and it cannot exceed ServerLimit times ThreadsPerChild. Set it higher and httpd logs a startup warning and silently lowers it to that product, so your intended concurrency never takes effect.

ProxyPass maps an inbound URL path to a backend and forwards requests. ProxyPassReverse works on the way back, rewriting Location, Content-Location and URI response headers so a backend redirect pointing at the internal address is translated into the public URL.

Caddy reads the site address as a public domain, so it obtains a certificate for example.com from a public ACME certificate authority, serves the site over HTTPS, redirects plain HTTP to HTTPS, and renews the certificate on its own. No TLS configuration is written anywhere.

Caddy's native config is JSON. The Caddyfile is human-friendly input that a config adapter converts to that JSON before loading. A running instance takes new config through its admin API, which listens on localhost:2019 and applies changes gracefully without restarting.

Each Caddy instance has its own private storage, so all six independently order certificates for the same names — and container restarts lose that storage and re-order again. The fix is one shared, persistent storage backend that every instance reads and writes.

Choose Caddy when certificate operations dominate the work — many or customer-supplied hostnames, small teams, no PKI runbook — and when a short config is worth more than fine-grained tuning. You give up tuning surface, operational precedent, and dynamic plugins, since third-party modules must be compiled in.

On-demand TLS lets customers point their own domains at your service with no config change, because Caddy issues per hostname at handshake time. Unrestricted, anyone aiming DNS at you triggers issuance attempts, so it must be gated by an ask endpoint that approves each name.

HAProxy config is split into global (process-wide settings), defaults (a template inherited by every proxy declared after it), frontend (a bind address that classifies incoming traffic), and backend (the server pool). A listen section fuses a frontend and backend into one block.

HAProxy's bare check keyword only opens a TCP connection to the server port. option httpchk makes the probe send an HTTP request instead, and http-check expect narrows success from any 2xx or 3xx reply to a specific status, regex or body string.

HAProxy evaluates use_backend rules top to bottom and the first one whose condition is true wins; if none match it uses default_backend. Space-separated ACL names in a condition are AND-ed, || is OR, and ! negates.

HAProxy adds Set-Cookie: SRVID=s1 to the first response so later requests carrying that cookie go back to s1. indirect strips the cookie before forwarding to the server and skips insertion when the client already sent a valid one; nocache marks the response private so shared caches cannot store it.

Declare a table storing http_req_rate(10s), track each request against it with http-request track-sc0 src, then deny with http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }. The track rule must come first, because the deny rule reads the counter that tracking populates.

spring-boot-starter-web pulls Tomcat in as an ordinary library, so the application starts a real Tomcat inside its own JVM process on port 8080. Setting server.port=0 makes it bind a random free port chosen by the operating system.

Tomcat derives the context path from the WAR's file name, so analytics.war deploys at /analytics. Name the file ROOT.war to serve it at the root path. With autoDeploy enabled, Tomcat scans webapps/ while running and deploys or redeploys changed files.

maxThreads caps how many requests Tomcat processes at once, maxConnections caps how many sockets it holds open, and acceptCount is the OS accept-queue length used once maxConnections is full. Past all three, new connections are refused.

Three properties bound it: server.tomcat.max-connections (default 8192) caps accepted connections, server.tomcat.threads.max (default 200) caps requests processed at once, and server.tomcat.accept-count (default 100) sizes the OS backlog beyond that. Idle CPU means the 200 threads are blocked, not busy.

The application's own copy wins: Tomcat's web application class loader searches WEB-INF/classes and WEB-INF/lib before the shared loader that owns $CATALINA_BASE/lib. Both copies then exist as distinct classes, so objects crossing between container and application fail with ClassCastException or NoClassDefFoundError.

An IIS application pool is the isolation boundary for one or more web applications. IIS runs each pool in its own w3wp.exe worker process, so a crash, a recycle, or an identity change affects only the applications assigned to that pool.

Both symptoms come from the worker process going away. The IIS application pool idle time-out kills w3wp.exe after 20 minutes with no requests, and periodic recycling restarts it roughly every 29 hours, discarding in-process session state and forcing a cold start on the next request.

By default the code runs as the application pool's virtual account, named IIS APPPOOL<PoolName>. Grant local folder access to that name directly. It has no network identity, so a UNC share must instead be granted to the server's computer account — or the pool switched to a domain account.

An IIS binding is the tuple protocol, IP address, port and host name (plus a certificate for HTTPS). Two sites whose tuples collide cannot both register their prefix with HTTP.sys, so the second fails to start. Give them distinct host names — with SNI enabled for HTTPS — or distinct IPs or ports.

Out-of-process, the IIS module launches your app as a separate process running Kestrel on a local port and reverse-proxies each request to it. In-process, it loads the runtime inside w3wp.exe and the app serves through IIS directly, which removes the extra hop and is faster.

Istio's PeerAuthentication sets what a workload's sidecar accepts on inbound connections: STRICT requires mutual TLS, PERMISSIVE accepts either mutual TLS or plaintext, DISABLE expects plaintext. The proxy performs the TLS, so application code is untouched.

The second container is istio-proxy, an Envoy-based sidecar added by Istio's injection webhook when the pod is created. Injected rules in the pod's own network namespace redirect the pod's inbound and outbound TCP traffic through that proxy, so application code never changes.

Once any ALLOW policy selects a workload, that workload becomes default-deny: anything not matched by an ALLOW rule is rejected with 403. Evaluation runs CUSTOM first, then DENY, then ALLOW, and a DENY match wins outright.

Istio injects through a mutating admission webhook selected by namespace labels — istio-injection=enabled or istio.io/rev=<revision> — with the pod-level sidecar.istio.io/inject label as an override. Check those labels, whether the pod predates them, revision mismatch after an upgrade, host-network pods, and webhook availability.

Subsets are defined in a DestinationRule, not in the VirtualService. A weighted split fails with 503 either because no DestinationRule defines those subset names, or because a subset's label selector matches no running pods, leaving it with zero endpoints.

Linkerd's linkerd2-proxy is a Rust sidecar built for one job, so each pod costs far less memory and CPU and exposes a smaller attack surface. The price is extensibility: no Wasm or Lua filters, and a narrower protocol and feature set.

Start from what is genuinely missing. Push edge and gateway concerns into an ingress tier, keep Linkerd for in-cluster mTLS and metrics, and treat migration to Istio as justified only by structural gaps such as non-Kubernetes workloads or per-request token policy.

linkerd viz stat reports success rate, requests per second and latency percentiles, computed from metrics that the linkerd2-proxy sidecars expose and the viz extension's Prometheus scrapes. A workload shows none of them when its traffic is not HTTP or gRPC.

Each proxy gets a short-lived leaf certificate from Linkerd's identity service, proving its Kubernetes ServiceAccount identity and signed by the issuer under the trust anchor. If the issuer or the anchor expires, issuance stops and mTLS fails across the whole mesh.

A retry budget caps retries as a proportion of ordinary requests — Linkerd's default allows roughly 20% extra plus a small floor — so a struggling dependency cannot be hit with a multiple of its normal load the way a fixed per-request retry count allows.

A Consul intention is an authorization rule that permits or denies traffic from one mesh service to another. It matches the service identity carried in the sidecar's mTLS certificate rather than a source IP address. When nothing matches, Consul falls back to the ACL default_policy.

By default Consul does not intercept outbound traffic. Each upstream is declared in the sidecar registration with a local_bind_port, and the application must dial 127.0.0.1 on that port. Transparent proxy mode instead installs iptables rules so all outbound traffic is redirected into the sidecar.

Server agents hold the catalog and replicate it through Raft with an elected leader. Client agents hold no catalog: they run local health checks, carry local registrations, take part in gossip, and forward requests to servers — which is why every node runs one.

DNS and /v1/health/service/<name>?passing return only the healthy instance. /v1/catalog/service/<name> returns both, because the catalog lists registrations regardless of health. A critical instance is still registered and returns automatically on recovery; a deregistered one is gone until something registers it again.

consul-template holds a blocking query per dependency in the template, re-renders when one changes, writes the file atomically and then runs the command. It will happily render an empty list if Consul answers with zero results, so guard the render, validate the config, and only then reload.

xDS is Envoy's family of discovery APIs: a management server streams listeners, routes, clusters and endpoints into a running proxy, applied with no restart. Only the bootstrap — node identity and how to reach that server — stays in a local file.

The router is Envoy's terminal HTTP filter: it sends the request upstream and ends the chain, so anything listed after it can never run. Envoy rejects such a config. Filters see requests in listed order and responses in reverse order.

A listener binds the port and selects a filter chain; the http_connection_manager network filter parses HTTP and runs the HTTP filters; its route_config picks a virtual host and a route that names a cluster; the cluster load-balances across its endpoints.

Envoy's response flags name the proxy-side cause of an abnormal stream: UH no healthy upstream host, UF upstream connection failure, UO circuit-breaker overflow, UT upstream request timeout, URX retry limit reached. They distinguish upstream faults from Envoy's own decisions.

LDS delivers listeners, RDS the route tables they name, CDS the upstream clusters routes point at, EDS the endpoint addresses inside those clusters, and SDS the TLS secrets. The dependency runs listener to route to cluster to endpoint, which is why updates are ordered CDS, EDS, LDS, RDS.

The instance posts its own metadata to the Eureka server and then heartbeats every 30 seconds to keep its lease alive. Callers download the whole registry, cache it in memory, and pick an instance themselves — Eureka never carries request traffic.

Four delays compound: the 90-second lease must expire, the eviction task runs only every 60 seconds, the server's read-only response cache holds a stale answer for 30 seconds, and each client refetches the registry every 30 seconds.

When heartbeats received drop below about 85% of what the server expects, Eureka stops evicting expired leases and keeps serving the entries it already has. It is a deliberate choice of stale data over an empty registry under partition.

Decide by asking what Eureka still knows that the platform does not. If everything lands in one cluster, the orchestrator's own readiness tracking makes Eureka a slower second source of truth and it should go; keep it only for reach beyond the cluster or for per-caller routing policy.

Each Eureka server forwards writes directly to every configured peer over HTTP, asynchronously and best-effort, marked so the peer does not forward them again. There is no leader and no quorum, so peers converge eventually rather than immediately.

After a configured number of consecutive failed checks the proxy marks the backend unhealthy and stops sending it new requests, while continuing to probe it. It rejoins the pool only after a configured number of consecutive successful checks.

A layer 4 proxy sees only connection data — source and destination IP and port, and for TLS the cleartext SNI hostname — and copies bytes through untouched. A layer 7 proxy parses each request, so it can route on path, method, headers or cookies.

Each instance keeps session state in its own memory, so round-robin sends the next request to an instance that never saw the login and treats the user as anonymous. At the proxy layer the fix is session affinity: pin a client to one backend.

A forward proxy acts for the clients and is configured on the client side, so the origin server sees only the proxy. A reverse proxy acts for the service owner, is deployed in front of the backends, and the client never knows it exists.

Terminating TLS means the load balancer holds the certificate's private key and completes the HTTPS handshake itself, so the browser-to-load-balancer hop is encrypted and the load-balancer-to-application hop is plain HTTP unless you separately encrypt it.