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-command

Use 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.

Ũhoro ũhĩtĩte