Ansible SOCKS Proxy: Which Machine Owns localhost?

A task using socks5h://127.0.0.1:65432 must run in the network environment where that listener exists. A tunnel working from the controller does not make it available at a managed host's loopback address—or inside an execution container.

For the failing task, establish four facts:

1. The host or container executing the network request.
2. Its effective user and Python interpreter.
3. The module's HTTP library or SDK.
4. The address where that process can reach the SOCKS listener.

The play's inventory target alone does not answer the first question. Modules use their configured connection, delegation can move execution, and a local connection can keep work on the controller. Controller-side lookups happen outside the remote module altogether.

For an OpenStack image task, inspect the installed openstack.cloud collection's requirements and its OpenStack SDK environment. curl succeeding elsewhere does not establish that SDK's SOCKS capabilities or dependencies.

If the API operation is intended to run locally, make that execution choice explicit and provide the setting there. If it runs remotely, choose a proxy reachable from that context. Ansible's task environment: affects the task process; it does not reconfigure every lookup or plugin, and the SDK still needs to support the scheme in that Python environment.

Keep two routes separate: SSH or ProxyJump gets Ansible to a host, while the module's HTTP client gets from its execution context to the API. A working first route does not configure the second. Exposing a controller-only listener to solve reachability also changes who can access it, so it is a deployment choice rather than an address correction.