Unit

Configure Apache HTTP Server as a Forward Proxy

Learn how to configure Apache HTTP Server as a restricted HTTP and HTTPS forward proxy, including access controls, CONNECT tunneling, authentication, testing, logging, hardening, and troubleshooting.

What a Forward Proxy Does

A forward proxy is an intermediary that clients explicitly use to reach external services. The client sends a request to the proxy, and the proxy sends a corresponding request to the destination server. The destination normally sees the proxy as the network source rather than seeing the original client directly.

The usual request path is:

1. The client is configured with the proxy hostname and port.
2. The client connects to Apache and may authenticate.
3. Apache checks the client ACL, destination rules, protocol rules, and port rules.
4. Apache connects to the origin server and relays the response to the client.
5. Apache records the transaction in its logs.

Forward proxies are commonly used for controlled outbound access, centralized logging, filtering, authentication, policy enforcement, and limited caching where the cache policy is appropriate. They can also provide one controlled egress point for internal networks.

A forward proxy is different from a transparent interception proxy. With an explicit forward proxy, browsers, operating systems, or applications are configured to use the proxy. A transparent proxy intercepts traffic without requiring each client to be configured, usually through routing or firewall mechanisms.

Forward Proxy and Reverse Proxy Comparison

Do not confuse a forward-proxy configuration with a reverse-proxy configuration. ProxyPass and ProxyPassReverse normally publish backend applications through Apache; they do not, by themselves, create a general client outbound proxy.

HTTP and HTTPS Proxying

For a normal HTTP request, the client sends an absolute URL to the proxy. Apache reads the destination host and path, connects to that host, and relays the HTTP response.

HTTPS normally uses the CONNECT method. The client asks Apache to create a TCP tunnel to a target host and port, for example example.com:443. After Apache returns a successful tunnel response, TLS is established between the client and the destination through that tunnel.

In a standard CONNECT tunnel, Apache can see the client address, target hostname and port, connection timing, byte counts, and tunnel result. It generally cannot inspect the HTTP paths, headers, or response contents inside the encrypted TLS stream. TLS interception is a separate architecture that requires a trusted certificate authority on managed clients, certificate generation, detailed policy, privacy review, and careful key protection.

Apache Modules and Dependencies

Apache's proxy capabilities are supplied by a family of modules. Package names and module-enable commands differ between distributions, so inspect the installed package documentation when a command is unavailable.

On Debian or Ubuntu, modules are commonly enabled with a2enmod. On RHEL-family systems, modules are often supplied by installed Apache packages and loaded through configuration files. Verify loaded modules before troubleshooting directive errors.

sudo a2enmod proxy proxy_http proxy_connect authz_core

Baseline Restricted Forward-Proxy Configuration

Place forward-proxy settings in the main server configuration or in an appropriate virtual-host context supported by your Apache version and distribution. Keep the configuration in a file managed by your operating system's Apache layout, and protect it from unauthorized modification.

ProxyRequests On enables forward-proxy request handling. It must not be enabled on an unrestricted public server. ProxyVia controls Apache's handling of the HTTP Via header. The header can identify proxy participation and is useful for standards-compliant proxy chains and diagnostics.

<IfModule proxy_module>
    ProxyRequests On
    ProxyVia On

    <Proxy "http://*">
        Require ip 192.0.2.0/24
    </Proxy>

    <Proxy "https://*">
        Require ip 192.0.2.0/24
    </Proxy>
</IfModule>

This example permits clients from the documentation subnet 192.0.2.0/24 to request HTTP and HTTPS destinations. Replace it with the actual trusted network, and do not use a documentation subnet in production. The effective policy should deny clients outside the intended networks.

The Proxy sections apply authorization rules to proxied destinations. Use destination patterns that are no broader than necessary. A broad pattern such as <Proxy "*"> can be useful when combining a general authentication requirement with separate restrictions, but it must never be left without a client authorization policy.

Client and Destination Access Controls

An access control list, or ACL, is a set of permit and deny rules. A safe forward proxy normally has at least two control dimensions:

• Client authorization: permit only trusted IP addresses, subnets, or authenticated users.
• Destination authorization: permit only required schemes, hosts, and ports.

For an internal-only proxy, a client rule might permit a private subnet and deny everyone else by default. Apache's current authorization syntax commonly uses Require ip, Require host, and authentication providers. Review rule inheritance carefully when several Proxy sections apply.

IP-based rules are predictable when clients have stable addresses or the proxy sees the expected source network. Hostname-based rules require DNS lookups and can be affected by forward and reverse DNS behavior, changing addresses, split-horizon DNS, or DNS compromise. Use hostname rules only when their resolution and operational consequences are understood.

Destination matching also has security implications. Do not use unrestricted destination matching merely to make configuration easier. Permit HTTP and HTTPS only when those protocols are required, and limit CONNECT to approved ports.

Limit HTTPS CONNECT to Port 443

AllowCONNECT restricts the ports that Apache may tunnel with CONNECT. Allowing only port 443 supports ordinary HTTPS browsing while reducing the chance that the proxy becomes a tunnel to SSH, databases, mail services, or other arbitrary TCP endpoints.

<IfModule proxy_connect_module>
    AllowCONNECT 443
</IfModule>

Some environments also require a permitted alternate TLS port. Add such a port only after documenting the need and reviewing outbound firewall policy.

Adding Proxy Authentication

Network restrictions may be insufficient when several users share a subnet, clients change addresses, or individual accountability is required. Proxy authentication requires the client to present credentials before Apache permits proxy access.

Basic authentication sends a username and password in a form that must be protected by transport security. Use it only where the connection between client and proxy is protected against credential disclosure, or where a separate secure access design provides that protection. Basic authentication does not encrypt the credentials by itself.

A file-backed identity source is a simple starting point:

<Proxy "*">
    AuthType Basic
    AuthName "Restricted Proxy"
    AuthUserFile /etc/httpd/proxy-users
    Require valid-user
</Proxy>

sudo htpasswd -c /etc/httpd/proxy-users proxyuser

The -c option creates a new file, so omit it when adding a user to an existing password file. Set ownership and permissions so Apache can read the file while unprivileged users cannot. Larger deployments may use LDAP or an external authentication system. Combine identity-based authorization with source-network restrictions when both controls are useful.

Configure Clients and Test the Proxy

Browsers usually have proxy settings for HTTP, HTTPS, and bypass exceptions. Operating systems may provide system-wide proxy settings. Command-line tools and applications often use environment variables, although support varies by application.

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

NO_PROXY lists names or addresses that should bypass the proxy. Use it for loopback services, internal domains, and destinations that have direct internal routing. Browser bypass syntax differs between products, so verify the result rather than assuming that every application interprets the list identically.

Test ordinary HTTP traffic with an explicit proxy URL:

curl -v -x http://proxy.example.internal:3128 http://example.com/

Test an HTTPS destination and observe the CONNECT exchange:

curl -v -x http://proxy.example.internal:3128 https://example.com/

With authentication, use a proxy credential option supported by the client, but avoid exposing passwords in shell history or process listings. A successful HTTPS test normally shows a successful CONNECT response followed by TLS negotiation. The final HTTP response comes from the destination, while the proxy's access log records the proxy transaction.

Logging, Monitoring, and Operations

Apache's access log and error log are the primary operational sources. Depending on the configured log format and Apache version, records can include the client source address, request method, destination host, request target, response status, response size, referrer, user agent, and timing information. CONNECT requests should be distinguishable from ordinary HTTP proxy requests.

Access logs help answer who connected, what destination was requested, whether authorization succeeded, and how many bytes were transferred. Error logs provide details about module failures, DNS errors, connection failures, authentication problems, and mandatory-access-control denials.

• Validate configuration before every reload.
• Use a graceful reload so existing connections can finish where appropriate.
• Check service status and active listening sockets after changes.
• Monitor unusual traffic volume, repeated denied requests, excessive CONNECT attempts, and connections to unexpected ports.
• Set retention and rotation policies before logs fill the filesystem.
• Restrict log-file permissions because URLs, usernames, client addresses, and destinations can be sensitive.
• Define whether query strings should be logged, since they may contain tokens or personal data.

sudo apachectl configtest
sudo systemctl reload apache2

sudo httpd -t
sudo systemctl reload httpd

Use the command set appropriate to the distribution. Service names are commonly apache2 on Debian-family systems and httpd on RHEL-family systems.

Security Hardening Checklist

• Never expose a forward proxy without explicit client access restrictions. An open proxy is reachable by untrusted users and may be abused for scanning, spam, attacks, or unwanted anonymity.
• Bind Apache to a trusted interface and restrict the proxy listener with host and network firewalls.
• Permit only required client IP ranges or authenticated identities.
• Allow only necessary destination schemes, normally HTTP and HTTPS.
• Use AllowCONNECT 443 or an equally narrow port policy instead of permitting arbitrary tunnels.
• Use authentication when network-level controls do not provide sufficient accountability.
• Protect password files and Apache configuration files with appropriate ownership and permissions.
• Keep Apache, its modules, and the operating system patched.
• Use outbound firewall rules as a complementary control. The proxy policy and network egress policy should both reject unauthorized destinations.
• Use rate limits or connection controls where supported by the surrounding firewall, load balancer, or monitoring platform.
• Alert on open-proxy behavior, unexpected destination ports, sudden traffic spikes, and repeated authorization failures.
• Document privacy, retention, and access policies for proxy logs.

Configuration and Troubleshooting Methodology

Troubleshoot in stages rather than treating every failure as an Apache proxy problem:

1. Client to proxy: confirm DNS, routing, listener address, listener port, and firewall access.
2. Proxy authorization: check the client ACL, destination rule, CONNECT port rule, and authentication result.
3. Proxy to destination: check destination DNS, outbound routing, egress firewall rules, proxy-to-server connectivity, and mandatory access controls such as SELinux.
4. Application exchange: inspect HTTP status codes, TLS negotiation, destination behavior, and response timing.

First verify loaded modules and then validate syntax before reloading:

sudo apachectl -M
sudo apachectl configtest

On RHEL-family systems, use httpd -M and httpd -t. Use curl -v to see proxy connection setup, authentication challenges, CONNECT responses, TLS negotiation, and destination responses. Correlate the request time and client address with Apache access and error logs.

Common Proxy Failure Responses

Specific Diagnostic Cases

If HTTP works but HTTPS fails, verify that mod_proxy_connect is loaded, CONNECT is allowed, the target port is included in AllowCONNECT, and outbound TCP 443 is permitted. Look for the CONNECT response in verbose curl output.

If clients receive 403, confirm the client source address Apache sees and review authorization inheritance. A common mistake is mixing older access-control syntax with current Require directives. Add only the intended network or authenticated identity.

If clients receive 407, check that credentials are being sent to the proxy rather than to the destination. Verify the password file path, ownership, permissions, and Apache error log messages.

If clients cannot connect to the proxy port, inspect active listeners, the configured bind address, host and network firewalls, the client hostname and port, and SELinux or another mandatory access-control system.

If a reload fails, run apachectl configtest or httpd -t, correct the exact file and line reported, verify module availability, and ensure each directive is in a valid server or virtual-host context.

Operational Boundaries

Apache can provide a controlled forward proxy, but it may not provide every feature expected from a dedicated forward-proxy platform. Evaluate caching, detailed filtering, identity integration, quota management, reporting, and high-scale connection handling against your requirements. Any caching policy must account for authorization, privacy, freshness, and sensitive content.

For related fundamentals, review HTTP concepts, computer networking, TCP and UDP ports, private IP addresses, and Apache configuration files.

Exam- and Operations-Relevant Notes

• ProxyRequests On enables forward-proxy behavior; it is not the same as ProxyPass.
• mod_proxy_http handles ordinary HTTP proxying, while mod_proxy_connect handles CONNECT tunnels.
• HTTPS through a standard proxy is usually an encrypted CONNECT tunnel, not TLS decryption by Apache.
• Restrict both the clients allowed to use the proxy and the destinations or ports the proxy may reach.
• A proxy exposed to untrusted users without restrictions is an open proxy and a security incident risk.
• Use syntax validation, logs, and verbose client output to separate listener, authorization, and outbound connectivity failures.