if you have worked with nginx, cloudflare, aws load balancers, or kubernetes ingress, you have already used proxies. the interesting part is that not every proxy works the same way.
the biggest difference is where the proxy operates in the networking stack. some only understand network connections, while others understand the application itself.
a layer 4 proxy operates at the transport layer. it understands tcp and udp connections, source and destination addresses, ports, and connection state.
it does not understand http requests, urls, cookies, headers, graphql queries, or json payloads. to it, every request is simply a stream of bytes moving between two endpoints.
when a client opens a tcp connection, the proxy accepts it, creates another connection to the backend, and forwards packets between both sides. it never needs to know what those bytes actually represent.
because it performs very little processing, it is extremely efficient and can handle millions of concurrent connections.
this makes it ideal for tcp load balancing, database traffic, ssh, redis, postgres, mqtt, and many other non-http protocols.
nginx supports this using the stream module.
stream { upstream postgres { server database:5432; } server { listen 5432; proxy_pass postgres; } }
in this example nginx only forwards tcp traffic to postgres. it has no understanding of sql statements or database queries.
a layer 7 proxy works one level higher at the application layer. instead of only forwarding bytes, it understands application protocols such as http, https, websocket, and grpc.
because it understands the request itself, it can inspect, modify, or route requests based on application data.
GET /api/users host: api.example.com authorization: bearer token
instead of seeing random bytes, the proxy now knows the request method, url, headers, cookies, host, and many other details.
this allows it to route /api requests to one service, static assets to another, and admin requests to a completely different backend.
it can also authenticate users, cache responses, compress data, inject headers, apply rate limits, and block malicious traffic before the request ever reaches your application.
this is exactly why nginx is commonly deployed as a reverse proxy.
server { listen 443 ssl; location /api { proxy_pass http://backend:3000; } location / { proxy_pass http://frontend:5173; } }
nginx reads the incoming http request, decides where it belongs, and forwards it to the appropriate backend service.
cdns like cloudflare also mainly operate at layer 7. every request first reaches the nearest edge server. if the requested asset is already cached, the response is returned immediately without contacting the origin server. otherwise, the cdn fetches the resource, stores it, and serves future requests directly from the edge.
this is also why cdns can apply waf rules, rate limiting, bot protection, caching, redirects, header rewriting, and many other application-level features.
in many production environments both proxy types are used together. a layer 4 load balancer distributes incoming tcp connections across multiple proxy instances, while a layer 7 proxy performs intelligent routing before forwarding requests to backend services.
one focuses on moving network connections as efficiently as possible. the other focuses on understanding application traffic and making decisions based on it.
once you understand this distinction, technologies like nginx, cloudflare, ingress controllers, api gateways, service meshes, and cloud load balancers become much easier to reason about.