Proxy Server Checker

An application behind a reverse proxy often sees the proxy’s address at the network connection while receiving the original client claim in an HTTP header. That split is useful for routing and logging, but unsafe when the application trusts header values without proving which proxy wrote them.

Observed remote address

The peer address seen by the receiving edge for the request being examined.

Forwarded chain

An ordered list of client and proxy claims carried in X-Forwarded-For or the for parameters of Forwarded.

Trusted edge hop

A known proxy at the right side of the chain whose address range and header-writing behavior are controlled by the operator.

First untrusted candidate

The address immediately to the left of the configured trusted edge window.

Standardized Forwarded fields and widely used headers such as X-Forwarded-For, Via, and CDN-specific client-address headers leave different clues. Their presence can reveal a proxy path, edge provider, scheme rewrite, or original-address claim. Their absence cannot prove that traffic was direct, anonymous, or outside a VPN.

Trust is evaluated from the receiving edge toward the client, so a comma-separated chain is read from right to left. Public clients can often supply their own forwarding headers. A trusted edge should remove, replace, or append them according to a documented policy, and the application must use the same trusted-proxy count or address ranges.

Header evidence supports several different questions. A privacy review asks whether an original address is disclosed. A reverse-proxy review asks which hop an application may trust. A CDN review asks whether the request arrived through the expected provider. The same headers can be relevant to all three, but they do not answer them with equal confidence.

How to Use This Tool:

Choose between local evidence review and an explicit check of the request currently reaching the service.

1. Select Paste headers to inspect a log or diagnostic block in the browser, or select Current request and press its check button to collect the service-visible proxy headers and remote address.
2. Choose Privacy or VPN check, Reverse-proxy log review, or CDN or load balancer edge. The profile changes the remediation plan, not the evidence score or classification.
3. Enter the access-log remote address when it is known, then set Trusted edge hops from 0 through 5. Count only proxies whose network path and header policy you control.
4. Enable Strict Forwarded syntax when RFC 7239 formatting is expected. Malformed segments become warning evidence rather than being silently accepted.
5. Review the trust path before using any client-address claim for access control, rate limits, audit logs, or abuse decisions.

Interpreting Results:

The classification describes recognized header evidence. The score measures how much of five evidence categories is present; it is neither a confidence percentage nor a proxy risk score.

• Transparent proxy signal combines chain evidence with more than one address-path row.
• CDN edge signal combines a CDN header with a forwarding chain or client-address hint.
• Anonymous proxy signal reflects disclosure such as Via without stronger chain evidence.
• No proxy header found means no recognized header was present. Check the observed network address, DNS, WebRTC, provider logs, or other relevant surfaces before concluding that no proxy or VPN was used.

Technical Details:

The analysis normalizes raw and CGI-style header names, redacts common credential and cookie fields, extracts recognized proxy signals, constructs one address chain, and then applies a right-edge trust window. Duplicate recognized headers remain separate evidence rows.

Transformation Core

X-Forwarded-For values are split on commas. RFC 7239 Forwarded values are split into comma-separated elements and semicolon-separated parameters. If both forms exist, the trust path uses the X-Forwarded-For chain; otherwise it uses Forwarded for values. An observed remote address is appended when it is not already present.

Rule Core

For a chain of length n and a configured trusted-hop count h, the trusted window begins at index max(0, n − h). Rows at or to the right of that index are marked trusted; the row immediately to its left is the first untrusted candidate. Setting zero trusted hops makes the rightmost row untrusted.

Formula Core

Each evidence category has a separate saturation point. The overall score is the rounded average of the five category percentages.

T_c is the sum of signal points in category c, M_c is that category’s maximum, and E_c is its 0–100 evidence percentage. Category maxima are 42 for client-address chain, 34 for client-address hints, 30 for proxy disclosure, 24 for edge identity, and 18 for scheme metadata. A multi-row address chain adds min(10, 3 × chain rows) points to the chain category before saturation.

Header values are limited to 320 characters for analysis, and pasted input is limited to 1,048,576 characters. Strict mode reports missing equals signs inside Forwarded elements, but it does not fully validate IP address syntax or reject every malformed extension value.

Privacy Notes:

Pasted headers and uploaded text are analyzed in the browser. Common authorization, cookie, proxy-authorization, and API-key header values are redacted if they appear in pasted evidence.

Current request is network-bound and runs only after its check button is pressed. The receiving service returns the observed remote address and a fixed set of proxy-relevant headers, truncates returned values to 320 characters, and marks the response not to be cached. Do not use this mode with a request context that contains secrets outside the normal browser headers.

Worked Examples:

References:

• RFC 7239: Forwarded HTTP Extension, RFC Editor, June 2014.
• IP Spoofing via HTTP Headers, OWASP Foundation.
• How to forward client IP headers with HAProxy, Simplified Guide.
• How to configure Nginx as a reverse proxy, Simplified Guide.