Proxy Server Checker

A web request often reaches an application after passing through several network devices and services. A home router, office gateway, VPN, forward proxy, content delivery network, load balancer, reverse proxy, ingress controller, or application firewall can all change what the receiving server sees. By the time an application writes an access log, the network connection may identify only the last edge hop, while HTTP headers carry claims about the earlier path.

Proxy headers are useful because they explain gaps between the address on the TCP connection and the address a user, CDN, or upstream service expects to see. They are also risky because most of them are ordinary request headers unless a trusted proxy removes untrusted input and writes fresh values. A client can forge X-Forwarded-For, a proxy can append values in the wrong order, and a CDN client-IP header is trustworthy only when the request really arrived through that CDN.

• Support teams compare browser IP reports with server logs when a customer appears to come from an unexpected address.
• Platform teams choose which hop should feed access logs, rate limits, geolocation, abuse controls, and trusted-proxy settings.
• Privacy reviewers look for VPN, relay, or transparent-proxy clues that may expose the original client address.
• Security teams check whether direct origin access or spoofed forwarding headers could bypass an edge policy.

Header families describe different evidence. X-Forwarded-For and Forwarded can carry address chains. Via, cache, and served-by headers show that an intermediary handled the request even when no client address is exposed. Provider headers such as CF-Connecting-IP, True-Client-IP, or edge request IDs can help correlate CDN traffic, but they still need provider range checks and origin-bypass protection.

A proxy review is a trust-boundary check, not a search for a single magic header. The same header block can support debugging, privacy review, or hardening work, but it cannot prove a visitor's identity by itself. It shows what the receiver observed and what the intermediaries chose to disclose.

How to Use This Tool:

Analyze one request observation at a time so the score, address chain, and playbook actions describe the same path.

1. Choose Check source. Use Paste headers for a raw request header block, access-log excerpt, or server environment dump. Use Current request when you want the checking service to observe the request reaching the site.
2. If you paste data, include proxy-related lines and Observed remote address when you have it. The parser accepts colon or equals style entries, folded lines, CGI-style names, REMOTE_ADDR, Forwarded, Via, X-Forwarded-For, and common CDN client-IP headers.
3. Select Analysis profile. Privacy or VPN check emphasizes leakage clues, Reverse-proxy log review emphasizes trusted-proxy configuration, and CDN or load balancer edge emphasizes provider ranges and origin-bypass checks.
4. Set Trusted edge hops to the number of controlled hops at the right end of the address chain. If you are unsure, start with 0 or 1, then compare the first untrusted candidate with the real reverse proxy, CDN, ingress, or load balancer path.
5. Turn on Strict Forwarded syntax when validating a standards-compliant edge. Leave it off for mixed server logs where malformed fragments would distract from the main forwarding evidence.
6. Read the summary, then compare Proxy Signal Ledger, Address Chain Ledger, Exposure Playbook, and Proxy Evidence Mix. If current-request mode reports that the service is unavailable, switch back to pasted headers or retry after the checking service is reachable.

A useful review ends with a plausible remote address, a trusted-hop count that matches real infrastructure, and a playbook action that can be verified outside the page.

Interpreting Results:

The evidence score measures recognized proxy, CDN, forwarding, edge-identity, and scheme-metadata signals in the submitted sample. It is not a privacy grade, a fraud score, or proof that a client-IP header is truthful. A high score usually means the request path left visible evidence; it does not mean the left-most address should drive access control, rate limiting, or abuse response.

The safest client candidate is normally the address immediately before the trusted edge window. Even that value may represent an untrusted proxy rather than a person or device. Use the Address Chain Ledger as a starting point, then confirm edge configuration, provider ranges, and origin reachability before changing security policy.

Technical Details:

Forwarding headers travel inside the HTTP message, while the observed remote address comes from the network connection seen by the receiving server or checking service. That split is the central technical limit: transport evidence identifies the final hop, and header evidence contains claims written by one or more intermediaries. Secure interpretation needs both.

X-Forwarded-For conventionally lists the original client first and later proxies after it. The standardized Forwarded header uses parameter pairs such as for, by, host, and proto. Via discloses intermediary handling rather than the original client address. CDN and platform headers can add a cleaner client-IP hint or request ID, but the final hop must still be trusted.

Rule Core:

Recognized headers are grouped by evidence type. Address-chain evidence is the most useful for a trust walk; disclosure and edge-identity evidence are still useful because they show that a proxy, cache, provider, or platform handled the request.

Trust Walk:

Address-chain interpretation starts with X-Forwarded-For when that chain exists. If it does not, Forwarded for values become the fallback. The observed remote address is appended when it is available and not already present, then Trusted edge hops marks the controlled positions at the right end.

Formula Core:

The score is an evidence-density percentage across five evidence areas. Each area accumulates weighted signal points, is capped at 100 percent, and then contributes one-fifth of the final score. A multi-hop address chain adds a small bonus to the client-address-chain area before the cap is applied.

E is the capped percentage for one evidence area, P is the weighted evidence present in that area, and C is that area's cap. A repeated header can fill one area, but a score near 100 requires evidence across the recognized categories.

Privacy and Accuracy Notes:

Pasted header analysis stays in the browser. Current-request mode is network-bound because the site has to observe the request reaching its checking service.

• Sensitive header values such as authorization, cookie, proxy-authorization, and API key fields are redacted in the evidence ledger.
• Current-request mode returns proxy-relevant request headers, the observed remote address, and the observation time; it does not prove what another origin or provider would see.
• Private, local, documentation, public-looking, and obfuscated address labels help triage a chain but do not replace provider range validation.
• A header score can rise because a request path is verbose, not because it is secure or privacy-preserving.

Worked Examples:

FAQ:

Glossary:

Forwarded

A standardized HTTP header that can carry for, by, host, and proto parameters for proxy paths.

X-Forwarded-For

A widely used non-standard header that lists client and proxy addresses, conventionally from original client to later proxies.

Observed remote address

The source address seen on the receiving network connection, usually the final hop before the application or checking service.

Trusted edge hop

A right-end chain position that belongs to infrastructure you control or explicitly trust.

First untrusted candidate

The address just before the trusted edge window, often the safest client candidate for logs or rate limits.

Via

An HTTP header that discloses intermediary handling rather than the original client address.

References:

• RFC 7239: Forwarded HTTP Extension, IETF, June 2014.
• X-Forwarded-For header, MDN Web Docs, July 4, 2025.
• Via header, MDN Web Docs, July 4, 2025.
• IP Spoofing via HTTP Headers, OWASP Foundation.
• Cloudflare HTTP headers, Cloudflare, May 5, 2026.
• How to configure Nginx as a reverse proxy, Simplified Guide.
• How to view HTTP request headers with curl, Simplified Guide.