VMware ESXi and vSphere Cluster Management

Proxy Servers: Types, Uses, Configuration, and Security

Learn how proxy servers relay network requests, compare forward and reverse proxies, configure clients and Nginx, understand headers, security, performance, and troubleshoot failures.

What Is a Proxy Server?

A proxy server is an intermediary that relays requests between a client and another network service. Instead of communicating directly with the destination, the client sends a request to the proxy. The proxy then communicates with the destination on the client's behalf and returns the response.

The client may be a person using a browser, an application using an API, or another server. The destination may be an origin server, an external website, or an internal backend.

1. The client creates a request for a destination.
2. The client sends the request to the proxy.
3. The proxy authenticates the client and applies policy if required.
4. The proxy connects to the destination or to an upstream service.
5. The proxy receives the response and sends an appropriate response back to the client.

A proxy can therefore serve users, applications, or servers. Its position and purpose determine whether it is called a forward proxy or a reverse proxy.

Why Proxies Are Used

• Privacy and IP masking: A destination commonly sees the proxy's source address instead of the client's address. This is not the same as guaranteed anonymity.
• Access control: Organizations can restrict destinations, ports, users, groups, or request methods.
• Content filtering: A proxy can block malware, unsuitable categories, large downloads, or selected file types.
• Caching: Frequently requested content can be stored and served locally, reducing bandwidth and latency.
• Logging and auditing: Proxies can record users, destinations, response codes, timing, and transferred sizes.
• Permitted route changes: A proxy can provide access through an approved network path when ordinary routing is restricted.
• Backend protection: A reverse proxy can hide origin servers and expose only controlled public endpoints.
• Traffic distribution: A reverse proxy can balance requests across multiple application servers.
• TLS handling: A reverse proxy can terminate TLS, inspect policy-relevant traffic, and create separate protected connections to backends.

Forward Proxies

A forward proxy represents clients when they access external resources. The client knows about the proxy and sends outbound requests to it before they reach the internet or another remote network.

A common organizational example is an employee browser using a company proxy. The proxy authenticates the employee, checks the requested destination against policy, records the request, and retrieves permitted content.

Explicit and Transparent Forward Proxies

With an explicit proxy, the browser, operating system, command-line tool, or application is configured with a proxy hostname and port. The client deliberately sends proxy-formatted requests to that endpoint.

A transparent proxy redirects traffic without requiring manual proxy settings on each client. Network devices may intercept selected traffic and send it to the proxy. Transparent interception can simplify deployment, but it can complicate HTTPS, application compatibility, troubleshooting, and user awareness.

Reverse Proxies

A reverse proxy is a public-facing service that represents one or more origin servers to incoming clients. Clients connect to the reverse proxy as though it were the application, while the proxy routes requests to an upstream backend.

For example, a public hostname can route requests to different services:

• Requests for api.example can go to an API service.
• Requests for shop.example can go to a commerce application.
• Requests under /images/ can go to a static-content service.

Routing can be based on the requested hostname, URL path, port, headers, or other policy inputs. Reverse proxies commonly provide TLS termination, caching, compression, rate limiting, request-size limits, health checks, and load balancing.

TLS Termination and Pass-Through

TLS termination means the reverse proxy decrypts HTTPS traffic. It can inspect HTTP details, apply application-layer rules, and then use HTTP or HTTPS for the backend connection. The client must trust the certificate presented by the proxy.

TLS pass-through means the proxy forwards encrypted TLS traffic without decrypting it. The backend owns the certificate and performs the TLS handshake. The proxy can usually route using limited connection information, such as an IP address or TLS hostname indication, but cannot inspect the encrypted HTTP path.

Forwarded Client Information

After a reverse proxy accepts a request, the backend normally sees the proxy's network address as the direct peer. If the application needs the original client address, scheme, or hostname, the proxy must pass that information in trusted headers. The application must be configured to trust those headers only from known proxy addresses.

Proxy Types Compared

Application-layer proxies understand protocols such as HTTP and can inspect methods, paths, headers, and response codes. Network-layer or connection-oriented proxies relay connections with less application-specific interpretation. SOCKS is commonly used as a general-purpose connection proxy.

Forward Proxy and Reverse Proxy Differences

HTTP, HTTPS, and SOCKS Request Behavior

HTTP Through an HTTP Proxy

For a direct HTTP request, the client connects to the destination and sends a request path such as GET /products HTTP/1.1. With an HTTP proxy, the client connects to the proxy and commonly sends an absolute URL, such as GET http://example.test/products HTTP/1.1. The proxy reads the destination from the request and forwards or serves it.

HTTPS Tunneling with CONNECT

For HTTPS through a forward proxy, the client commonly sends CONNECT host:443 HTTP/1.1. If the proxy permits the request, it returns a successful response and relays bytes in both directions. The client then performs the TLS handshake through that tunnel. A normal forward proxy cannot read the encrypted HTTP contents in this mode.

Do not confuse this with reverse-proxy TLS termination. In CONNECT tunneling, the client and destination typically negotiate TLS end to end. In TLS termination, the reverse proxy negotiates TLS with the client and separately communicates with the backend.

SOCKS

A SOCKS proxy accepts a connection request and relays a network connection. SOCKS commonly handles TCP and may support UDP depending on the implementation and configuration. The application must support SOCKS directly or use a compatible adapter. DNS behavior matters: a local DNS lookup can reveal the requested hostname outside the proxy, while a mode such as socks5h asks the proxy to resolve it where supported.

Proxy Headers and Client Identity

Applications should define trusted proxy IP ranges or trusted network interfaces. They should remove or replace incoming identity headers at the edge when those headers arrive from untrusted clients. Otherwise, a client may claim to be a different IP address, cause incorrect audit records, bypass IP-based controls, or influence generated URLs.

Proxy Configuration Concepts

A client proxy configuration normally includes:

• Host and port: The network address where the proxy listens.
• Protocol: HTTP, HTTPS, or SOCKS, which describes how the client communicates with the proxy.
• Authentication: Credentials or another supported mechanism required by the proxy.
• Bypass list: Hosts, domains, addresses, or schemes that should use direct connections.
• NO_PROXY exclusions: A commonly supported environment-variable form of the bypass list.

Proxy settings can be configured at the operating-system level, in a browser, in a command-line tool, or inside an individual application. Application-specific settings may override system settings. Some services do not read shell environment variables at all.

Environment Variables

export HTTP_PROXY=http://proxy.example.net:8080
export HTTPS_PROXY=http://proxy.example.net:8080
export NO_PROXY=localhost,127.0.0.1,.internal.example

Many tools also recognize lowercase forms such as http_proxy, but precedence differs. Check the specific tool's documentation and inspect the effective environment before diagnosing a failure.

PAC Files and Automatic Discovery

A PAC file is a Proxy Auto-Configuration script that selects a proxy based on the requested URL, hostname, or network conditions. Automatic discovery allows a client to find proxy settings through a managed network mechanism. These approaches simplify centralized administration, but clients must be able to retrieve the configuration securely and consistently.

Practical Client Examples

Use an explicit HTTP proxy with a command-line client:

curl --proxy http://proxy.example.net:8080 https://www.example.com/

Use a SOCKS5 proxy and request proxy-side DNS resolution:

curl --proxy socks5h://proxy.example.net:1080 https://www.example.com/

Inspect response headers while using an HTTP proxy:

curl -I --proxy http://proxy.example.net:8080 https://www.example.com/

These commands demonstrate explicit configuration. They do not prove that every application on the system uses the same proxy.

Reverse Proxy Configuration Example

The following illustrative Nginx configuration sends requests to an application backend and preserves commonly needed request information:

location / {
    proxy_pass http://app_backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

An upstream pool can distribute requests across two backend servers:

upstream app_backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

In production, also define suitable TLS settings, access controls, timeouts, request-size limits, health checks, logging rules, and a clear policy for trusted proxy addresses. Configuration syntax and security defaults differ between proxy products.

Proxy Authentication and Authorization

Proxy authentication is credential verification performed before the proxy permits a request. Basic proxy authentication sends a username and password using an encoded representation; encoding is not encryption. Use an encrypted connection to the proxy when credentials or request contents could otherwise be exposed.

Authorization determines what an authenticated identity may do. Policies may differ by user, group, destination category, method, port, bandwidth, time, or request size. Service credentials should be stored in a secret manager or protected service configuration rather than source code, shell history, or publicly readable files. Rotate them and grant only the required permissions.

Security and Privacy Considerations

• A proxy does not automatically encrypt traffic between every pair of endpoints.
• An operator may see destination names, timing, sizes, client identities, and unencrypted content.
• Untrusted public proxies can modify traffic, inject content, collect credentials, or record browsing activity.
• HTTPS certificate inspection deliberately terminates and re-encrypts TLS so the proxy can inspect content. It requires a trusted inspection certificate and has significant privacy and governance implications.
• Administrative proxy endpoints, configuration interfaces, metrics, and logs must be protected with network restrictions and strong authentication.
• Rate limits, request-size limits, connection limits, and backend isolation reduce abuse and resource exhaustion.
• Logs should have a defined retention period. Avoid collecting unnecessary credentials, tokens, personal data, and request bodies.
• Do not treat a forwarded client IP as proof of identity. It is metadata supplied by a trust-controlled network component.

Performance and Reliability

Caching

A proxy may cache public responses and serve repeated requests without contacting the origin. Cache rules must respect freshness, validation headers, authorization, cookies, and private data. Incorrect invalidation can serve stale content or expose one user's response to another.

Connections and Timeouts

Connection pooling and keep-alive reuse established connections, reducing handshake overhead. Proxies also need separate connection, send, and read timeouts. Retries can improve reliability for safe operations, but careless retries of non-idempotent requests can duplicate actions.

Buffering and maximum request sizes affect memory, latency, uploads, and denial-of-service exposure. Tune them based on application behavior rather than increasing every limit when an error occurs.

Load Balancing and Availability

Load balancing distributes requests across multiple backends. Common approaches include round robin, least connections, and weighted selection. A health check tests whether a backend is available and removes failed instances from rotation.

A single proxy can become a single point of failure. High-availability deployments use multiple proxy instances, redundant network paths, shared or replicated configuration, and an appropriate way to direct clients to healthy instances.

Common Proxy HTTP Status Codes

Troubleshooting Proxy Connectivity

1. Confirm effective settings. Check the application's own proxy configuration, environment variables, operating-system settings, PAC result, and bypass list. Do not assume that a configured browser proxy applies to a service.
2. Separate name resolution from connectivity. Determine whether the client or proxy resolves the destination. Check DNS from the relevant host, then check routing and firewall access to the proxy and upstream.
3. Check authentication. A 407 response usually means that credentials are missing, wrong, expired, or incompatible with the required method.
4. Check certificates. For HTTPS failures, determine whether the client trusts the proxy's certificate, whether TLS inspection is enabled, and whether the destination certificate is valid.
5. Check proxy and backend logs together. A request may reach the proxy but fail before reaching the backend, or the backend may return an application error that the proxy relays.
6. Compare direct and proxied access when policy permits. A direct success and proxied failure points toward proxy policy, authentication, proxy DNS, proxy routing, or TLS handling. Never bypass required organizational controls on an unauthorized network.
7. Check timing. Distinguish connection timeout, upstream response timeout, and client timeout. Investigate slow databases or dependent services before simply increasing limits.

Typical Failure Scenarios

407 Proxy Authentication Required: Confirm the configured address and port, verify the account and authentication method, and avoid placing credentials in shell history or source code.

502 Bad Gateway from a reverse proxy: Check that the backend process is running and listening, test connectivity from the proxy host to the upstream address and port, and review both proxy error logs and backend logs.

504 Gateway Timeout: Measure upstream response time, investigate backend bottlenecks, and then review proxy connect, send, and read timeout values.

The application reports the proxy IP: Confirm that the proxy sends X-Forwarded-For or Forwarded, configure the application with trusted proxy ranges, and reject forwarded headers supplied directly by untrusted clients.

HTTPS fails only through the proxy: Check whether CONNECT is permitted to the destination port, whether an inspection certificate is trusted, whether the proxy can resolve and reach the destination, and whether authentication is required.

Internal traffic uses the external proxy: Add loopback addresses, internal domains, and required private endpoints to NO_PROXY. Verify the syntax supported by the specific client and confirm that the application honors environment exclusions.

Exam-Relevant Notes

• A forward proxy represents clients; a reverse proxy represents origin servers.
• CONNECT commonly creates an HTTPS tunnel through a forward HTTP proxy.
• TLS termination decrypts traffic at the proxy; TLS pass-through does not.
• X-Forwarded-For and Forwarded must be trusted only across a controlled proxy boundary.
• HTTP 407 indicates proxy authentication is required, 502 commonly indicates an invalid or unreachable upstream response, and 504 commonly indicates an upstream timeout.
• NO_PROXY excludes selected hosts from proxying, but exact matching behavior is client-dependent.
• Caching improves efficiency but requires correct freshness, privacy, and invalidation rules.

For a concise reference to this lesson, see the proxy server topic.