Can a Website Tell NAT from a Forward Proxy?
Evaluate what a shared public IP, forwarding headers, and a proxy-check result can establish about the route to a website.
Several visitors arrive from one public address. That fits an office NAT gateway. It also fits a shared forward proxy. The address alone does not choose between them.
NAT changes address information along the path. A forward proxy accepts a connection and makes an onward connection. Those are different mechanisms, but a destination sees the connections that reach it, not a complete inventory of the client's network equipment.
An HTTP Via field can provide evidence of HTTP intermediaries. Treat its absence more narrowly: this request did not expose that indicator to this observer. Headers may be untrusted, removed, or unavailable inside an ordinary end-to-end TLS tunnel. IP reputation databases provide another kind of evidence, with their own coverage and age.
That is why “no proxy detected” on a checker is not a network diagram. It also cannot certify that every other website will reach the same conclusion.
If you operate the client or network, combine the endpoint's observations with the actual application settings, gateway configuration, and relevant connection records. If you only operate the website, describe what your signals support and allow for uncertainty.
For access controls, decide what you need to protect. A shared address can be useful for a coarse rate limit while being a poor stand-in for one person. Calling it NAT or a proxy does not resolve that identity problem.