Distorting Proxies
A distorting proxy puts a false client IP address into an HTTP request header. It hides the real address in that field, but the request can still contain signs of proxy use. Replacing one field alone does not prove that the real address is absent from the rest of the request. The word “distorting” refers to this substitution of information about the client.
The term comes from the older classification of proxy anonymity levels. Modern commercial proxies are expected to behave as Elite / High Anonymity proxies: they do not forward the client's original IP or add headers announcing proxy use. Distorting is mainly useful for understanding older descriptions and labels in public proxy lists.
What changes in the request
Suppose your public IP is 198.51.100.24, and the proxy connects to the website from 203.0.113.80. In an unencrypted HTTP request, it supplies a third address in a header: X-Forwarded-For: 192.0.2.55.
That third address is a false value inserted by the proxy. It is neither your real IP nor the address used to connect to the website.
Other headers may still indicate that an intermediary handled the request. For example, a Via header records the involvement of a proxy. Replacing the client IP does not remove that signal.
What the website actually sees
The connection still comes from 203.0.113.80. Putting another address in a header does not move the proxy to another country or change the network and reputation associated with its IP. Changing the false value between requests is not real IP rotation: the connection address remains the same.
An IP checker may display the connection address or a value taken from a header. That can produce different results for the same proxy. Seeing the false address on a test page does not mean every website will treat it as your IP.
Each website decides which headers to use and whose values to trust. A server might accept client IP information only from its own reverse proxy. A proxy you use to visit that website does not automatically become a trusted source.
Does this apply to HTTPS?
The example requires the proxy to be able to read and modify the HTTP request. With an ordinary HTTPS tunnel established using CONNECT, the request and its headers travel inside an end-to-end TLS connection. A proxy that only relays this encrypted traffic cannot insert a false IP into those headers. A Distorting result from a plain HTTP test therefore does not automatically describe the same proxy's behavior with HTTPS.