Podman pasta: Reach a Host Loopback Proxy from a Rootless Container
Use pasta’s namespace-to-host TCP forwarding for an existing loopback proxy and keep it distinct from publishing a container port.
The host’s 127.0.0.1:8118 and the container’s 127.0.0.1:8118 are normally separate loopback endpoints. Passing a proxy variable into a rootless container does not join those loopback interfaces.
For a Podman deployment using pasta, its namespace-to-host TCP forwarding can expose the intended host port inside the namespace:
podman run --network=pasta:-T,8118 \
--env http_proxy=http://127.0.0.1:8118 \
--env https_proxy=http://127.0.0.1:8118 \
existing-image application-commandUse the application’s existing image and command. The example assumes a working host-side HTTP proxy on port 8118 and a Podman/pasta version supporting the shown forwarding option.
pasta’s uppercase -T forwards from the target namespace toward the host namespace. Lowercase -t and Podman’s --publish address the opposite direction. Publishing container port 8118 therefore does not, by itself, make the host’s proxy available to the container.
Podman disables automatic namespace-to-host port forwarding by default; the explicit port chooses the service required here. The separate pasta:--map-gw option concerns reaching the host through the gateway address, which is another arrangement.
With Compose, inspect the actual provider and generated network configuration. A named bridge network is not automatically a pasta namespace just because an independent podman run command used pasta successfully. A remote Podman engine also places “host” at the engine’s location.