Proxy Server Checker

Evidence {{ analysis.score }}/100 Signals {{ signalRows.length }} Chain {{ chainRows.length }} {{ profileLabel }}

Client Proxy Edge App {{ analysis.score }}%

Check source:

Pasted headers stay local. Current request mode is network-bound and uses the tool Lambda when available.

Paste headers Current request

Current request check:

Use this when the Lambda is deployed; failures leave the pasted sample untouched.

Analysis profile:

Pick the reason you are reviewing these headers before reading the playbook.

Observed remote address:

Paste the access-log remote address when you have it; leave blank when reviewing only header text.

Trusted edge hops:

The address ledger walks from the right side of the chain to find the first non-trusted client candidate.

hop(s)

0 {{ trustedHopLabel }} 5

Request headers:

Recognizes raw headers, CGI-style `HTTP_` names, `REMOTE_ADDR`, `Forwarded`, `Via`, and common CDN client-IP headers.

Strict Forwarded syntax:

Leave off for mixed server logs; turn on when validating proxy output for a standard-compliant edge.

Header	Signal	Strength	Observed value	Finding	Copy
{{ row.header }}	{{ row.signal }}	{{ row.strength }}	{{ row.value }}	{{ row.finding }}

Position	Address or token	Source	Role	Trust note	Copy
{{ row.position }}	{{ row.address }}	{{ row.source }}	{{ row.role }}	{{ row.note }}

Priority	Action	Reason	Owner	Copy
{{ row.priority }}	{{ row.action }}	{{ row.reason }}	{{ row.owner }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Proxy headers are clues left by forward proxies, reverse proxies, load balancers, privacy relays, and CDN edges as an HTTP request moves toward an application. They can explain why a server log shows the edge address instead of the visitor address, why rate limits group users together, or why a privacy check still sees forwarding evidence.

Client address headers need careful interpretation because many of them are ordinary request headers. A caller can send a forged value unless the controlled edge removes, rebuilds, or appends the header before the application trusts it. The useful question is not only whether X-Forwarded-For, Forwarded, Via, or a CDN client-IP header appears, but which hop added it and whether the right end of the chain is under your control.

Proxy header trust path from client claim through proxy chain to trusted edge and application

Transparent proxies usually leave client-address evidence. Anonymous or opaque proxies may leave only a Via, cache, or gateway hint. CDN edges often use provider-specific client-IP headers as a cleaner single-address source, but those values are trustworthy only when the observed remote address really belongs to the expected provider range.

Proxy evidence can guide debugging, privacy review, support escalation, and hardening work. It should not be treated as proof of a visitor's identity by itself, especially when the origin can be reached without passing through the trusted edge.

How to Use This Tool:

Check one observed request at a time so the evidence score, signal rows, address chain, and playbook recommendations describe the same traffic path.

Choose Check source. Use Paste headers for a raw request header block, access-log excerpt, or server environment dump. Use Current request only when the checking service is available and you want it to observe the request reaching the site.
If you paste data, include the proxy-related lines and the Observed remote address when you have it. The parser recognizes raw header format, CGI-style names, REMOTE_ADDR, Forwarded, Via, X-Forwarded-For, and common CDN client-IP headers.
Select Analysis profile. Privacy or VPN check emphasizes leakage and comparison checks, Reverse-proxy log review emphasizes trust-boundary setup, and CDN or load balancer edge emphasizes provider range and origin-bypass risks.
Set Trusted edge hops to the number of controlled hops at the right end of the address chain. If you do not control the last proxy or are unsure, start lower and treat the first untrusted candidate with caution.
Turn on Strict Forwarded syntax when you are validating a standards-compliant edge. Leave it off for mixed logs where malformed snippets are expected and would distract from the main proxy evidence.
Read the summary first, then open Proxy Signal Ledger, Address Chain Ledger, Exposure Playbook, and Proxy Evidence Mix. If the current-request path reports that the service is unavailable, switch to pasted headers or retry after the service is deployed.

A useful first pass ends with a plausible observed remote address, a trust-hop count that matches your edge design, and a playbook row that names the next verification step.

Interpreting Results:

The evidence score measures how much recognized proxy, CDN, and forwarding evidence appears in the sample. It is not a privacy guarantee, a fraud score, or proof that a header value is truthful. A high score often means the request path is visible; it does not mean every listed address can be trusted for rate limiting, allowlisting, or security decisions.

Proxy checker result cues and follow-up checks
Visible cue	Best first reading	What to verify next
Transparent proxy signal	Forwarding evidence and an address chain are present.	Confirm that the rightmost trusted hops match the actual reverse proxy or load balancer path.
CDN edge signal	A provider-style client-IP header appears with chain or client-IP evidence.	Check that the observed remote address belongs to the expected CDN or load balancer range before trusting the client-IP header.
Anonymous proxy signal	Disclosure headers exist, but the original client address is not clearly exposed.	Compare browser IP, DNS, WebRTC, and reputation checks if privacy is the concern.
Forwarded chain needs trust review	Strict syntax found a malformed `Forwarded` segment.	Fix the producing proxy or turn strict checking off if the pasted source is only a mixed operational log.
No proxy header found	No recognized proxy or CDN header was present in the sample.	Do not assume the path is direct; opaque proxies, NAT, and provider logs may still affect the remote address.

For security-sensitive use, trust starts from infrastructure you control. Use the Address Chain Ledger to find the first untrusted candidate, then confirm edge configuration and provider ranges outside the page before changing access rules.

Technical Details:

Forwarding headers sit above the transport connection. The observed remote address comes from the connection seen by the receiving server or edge, while headers such as X-Forwarded-For and Forwarded are message fields that may have been appended, rewritten, preserved, or forged before the request arrived. This distinction is why the remote address and forwarded chain need to be read together.

X-Forwarded-For conventionally lists addresses from the original client on the left toward the most recent proxy on the right. The standardized Forwarded header uses parameters such as for, by, host, and proto. Via discloses intermediaries and protocol handling, but it usually does not identify the original client. CDN headers such as CF-Connecting-IP, True-Client-IP, and Fastly-Client-IP are provider-specific shortcuts that still require a trusted provider boundary.

Rule Core

The signal ledger groups recognized headers by what they imply about the request path.

Proxy signal groups and checked header examples
Evidence area	Header examples	Meaning
Client address chain	`Forwarded`, `X-Forwarded-For`, `Forwarded-For`	Shows a hop list or standardized forwarding parameters that may expose client and proxy addresses.
Client address hints	`X-Real-IP`, `Client-IP`, `CF-Connecting-IP`, `True-Client-IP`, `Fastly-Client-IP`	Shows a single-address claim often added by a reverse proxy, CDN, or load balancer.
Proxy disclosure	`Via`, `X-Cache`, `X-Served-By`, `Server-Timing`	Shows intermediary, cache, or gateway evidence even when no original client address is visible.
Edge identity	`CF-Ray`, `X-Amz-Cf-Id`, `X-Vercel-Id`, `Fly-Request-Id`	Shows provider trace IDs or edge request IDs that help correlate traffic with platform logs.
Scheme metadata	`X-Forwarded-Proto`, `X-Forwarded-Host`, `X-Forwarded-Port`	Shows original scheme, host, port, or route metadata used by applications behind a proxy.

Trust Walk Rules

The address chain is selected from X-Forwarded-For when present; otherwise, Forwarded for values are used. The observed remote address is appended when it is available and not already present. The trusted-hop count then marks the controlled rightmost hops and identifies the first untrusted candidate immediately to their left.

Proxy address chain trust walk roles
Role	How it is assigned	Interpretation limit
Left-most client claim	First address token in the selected forwarding chain.	Useful for debugging, but not trustworthy for security unless every hop to its right is controlled.
Intermediate hop	Address token between the first claim and the configured trusted edge window.	May be a user proxy, corporate gateway, privacy relay, or forged text.
First untrusted candidate	The address immediately left of the trusted edge hops.	The safest client candidate for security use, but it can still be an untrusted proxy rather than the actual user.
Trusted edge hop	Rightmost address positions covered by the Trusted edge hops value.	Only valid when those hops match infrastructure you operate or explicitly trust.
Observed edge	The remote address seen by the receiving server or checking service.	Strong evidence for the final hop, but not enough to reveal the original client by itself.

Formula Core

The percentage score averages five evidence areas after each area is capped at 100 percent. It is an evidence-density score, not a safety score.

E_{c} = \min (100, round (\frac{P_{c}}{C_{c}} \times 100))

score = round (\frac{\sum E_{c}}{5})

E is the evidence percentage for one area, P is the weighted evidence found in that area, and C is that area's cap. The chain area also receives a small bonus when more than one address-chain row is available.

Proxy evidence category caps
Evidence area	Cap	High-value signal
Client address chain	42	`X-Forwarded-For` and `Forwarded` carry the largest chain weights.
Client address hints	34	CDN client-IP headers and direct client-IP hints raise this area.
Proxy disclosure	30	`Via`, cache, and proxy markers show intermediary disclosure.
Edge identity	24	Provider request IDs raise this area even without a client address.
Scheme metadata	18	Forwarded scheme, host, port, prefix, and original-host hints raise this area.

Privacy and Accuracy Notes:

Pasted header text is analyzed in the browser. The current-request path sends a live request to the checking service so the service can report the proxy-relevant headers and remote address it observed. Avoid pasting secrets, session cookies, bearer tokens, signed URLs, private customer records, or headers from traffic you are not authorized to inspect.

Header values can contain personal data such as IP addresses, internal hostnames, provider request IDs, and routing details.
Common sensitive headers are redacted from parsed evidence, but a pasted log can still contain secrets in unrelated lines.
The current-request result reflects the checking service's network position, not every path a user, office network, crawler, or mobile carrier may take.
Provider-specific client-IP headers should be trusted only after you verify the request came through that provider and direct origin access is blocked.

Worked Examples:

Transparent reverse proxy review

A log excerpt contains X-Forwarded-For: 203.0.113.10, 198.51.100.2 and an Observed remote address of 198.51.100.2. With Trusted edge hops set to 1, the Address Chain Ledger marks 203.0.113.10 as the first untrusted candidate and 198.51.100.2 as the trusted edge hop. The Exposure Playbook should lead with trusted-proxy configuration and logging both values for auditability.

CDN edge with provider client-IP header

A CDN sample includes CF-Connecting-IP: 203.0.113.44, True-Client-IP: 203.0.113.44, X-Forwarded-For: 203.0.113.44, 198.51.100.15, and Observed remote address 198.51.100.15. The summary can show CDN edge signal and the Proxy Evidence Mix will raise both client-address and edge evidence. Before using the client-IP value for access control, verify that 198.51.100.15 is an expected provider address and that the origin cannot be reached directly.

Anonymous proxy symptom

A privacy check contains Via: 1.1 proxy-23.example.net, X-Cache: HIT from cache-gateway, and no forwarding chain. The Proxy Signal Ledger records disclosure evidence, while the Address Chain Ledger reports that no address chain is available. Treat that as proxy presence evidence, not as a way to identify the original client.

Malformed Forwarded header

A standards review turns on Strict Forwarded syntax for Forwarded: for 203.0.113.5;proto=https. The Proxy Signal Ledger adds a warning because the segment lacks the required equals sign. Fix the producing proxy or collect a cleaner raw header block before trusting the chain walk.

FAQ:

Can a high evidence score prove that a proxy is leaking my real IP?

No. The score shows recognized forwarding evidence. Use Proxy Signal Ledger and Address Chain Ledger to see which values appeared, then compare browser IP, DNS, WebRTC, and provider logs when privacy is the concern.

Which address should I use as the client IP?

For security decisions, use the first untrusted candidate only after the rightmost trusted hops match your controlled edge. Do not use the left-most X-Forwarded-For address by itself when clients can reach the origin or send their own forwarding headers.

Why does current request mode fail in some builds?

The current-request path depends on the checking service being available. When it is unavailable, the page leaves pasted sample data untouched and reports the failure so you can switch to Paste headers.

Can I drop an access log file into the header box?

Yes, for small text-like files. The page accepts plain text, log, and header files up to 1 MiB, then reads recognized header lines and ignores lines that do not look like header or environment entries.

Why did strict Forwarded syntax add a warning?

Forwarded uses parameter pairs such as for=, by=, host=, and proto=. Strict mode warns when a segment is malformed, which is useful for edge validation but noisy for messy operational logs.

Glossary:

Forwarded: A standardized HTTP header for proxy information such as client, proxy, host, and protocol values.
X-Forwarded-For: A common non-standard header that lists client and proxy addresses from left to right.
Via: An HTTP header used by intermediaries to disclose message forwarding and protocol handling.
Observed remote address: The network address seen by the receiving server or checking service for the final hop.
Trusted edge hop: A rightmost address-chain position that belongs to infrastructure you operate or explicitly trust.
First untrusted candidate: The address immediately before the trusted edge window, used as the safest client candidate when the trust boundary is correct.
CDN edge: A provider-controlled front door that can add client-IP and request-ID headers before forwarding traffic to an origin.

References:

RFC 7239: Forwarded HTTP Extension, IETF, June 2014.
RFC 9110: HTTP Semantics, Via header field, IETF, June 2022.
X-Forwarded-For header, MDN Web Docs, July 4, 2025.
IP Spoofing via HTTP Headers, OWASP Foundation.
Cloudflare HTTP headers, Cloudflare, May 5, 2026.
Fastly-Client-IP, Fastly Documentation.