A visitor clicks a button. Your PHP server calls an external API. The API sees the server's outgoing connection, or the exit of the proxy configured for that connection. The visitor's browser is handling a separate connection to your website.

Copying the visitor's address into a header cannot move the PHP connection onto the visitor's network. Headers are data sent over an already established connection. A destination may use a trusted forwarding header in its own application logic, but that does not turn the header value into the connection's source address.

A proxy has to accept the connection

To send PHP cURL through another machine, that machine needs to offer a reachable proxy service with permission to carry the request. The PHP process must be able to connect to it. A visitor's ordinary browser session gives your server no such general-purpose proxy endpoint.

The libcurl proxy option selects the service cURL connects to. It cannot ask an arbitrary browser to originate the request on its behalf.

A browser request is a different design

For some APIs, the browser can call the destination directly. That places the request on the user's network path, subject to their own proxy configuration. It also requires an API designed for browser clients. Cross-origin access follows CORS, and credentials sent to browser code become available to that client.

Decide where the request belongs before choosing a proxy option. Keep server credentials on the server; use a documented browser integration when the service supports one. Neither design offers a reliable shortcut for making a server request inherit a visitor's network identity.

Winndannde jowitiiɗe heen