I am using rootless podman with podman-compose. I have an issue where podman containers are unable to access the host's http proxy unless host networking is enabled. Host networking is not desirable for security and cleanliness reasons - I would like to seamlessly proxy outbound traffic from the pod.
I have tried passing the http_proxy environment variable directly and attempting to access the proxy via http://host.containers.internal as well to no avail.
I understand your frustration because I had to deal with the same problem, or at least something very similar.
TLDR is, yes it's possible with podman, but involving compose makes it difficult, if not impossible.
Let's first put aside the whole issue of using compose and focus on podman itself for now.
So by default, when running a single rootless container using podman run, your podman installation uses either slirp4netns or pasta to perform network namespace translation. You can check which one's the default using this command: podman info | grep rootlessNetworkCmd. passt.top has some great graphics to give you a brief idea of what they do, but the TLDR is that containers within their own network namespace cannot access the host's network (the default namespace). This is by design due to security concerns, and is the root of your problem.
Both slirp4netns and pasta actually allow you to create exceptions with varying degree of granularity. slirp4netns has allow_host_loopback; pasta has --map-gw and -T; see man podman-run, man slirp4netns, and man pasta.
Personally, I've found reasonable success using pasta. Assuming you've got privoxy running on 8118/tcp on your host machine, you can use the following argument to podman run to map the port into the container's network namespace: --network pasta:--map-gw,-T,8118. Then within the container, 127.0.0.1:8118 will allow you access to the proxy.
Okay, now onto the can of worms that is compose. The problem about compose is that it was and still is designed for docker, which at its inception had little consideration for running rootless (and to this day, still has very poor support for it). So naturally, docker had no reason to create something like slirp4netns or pasta, since the whole idea is to create for the container "the illusion of being root" while it's actually running rootless. Hence the compose standard has no official support for slirp4netns or pasta (ref). The default network driver when using compose is typically bridge, which does not afford such luxuries as port forwarding.
From podman's perspective, the creation of podman-compose (and the interoperability with docker-compose as a plugin) stem entirely from the desire for easy transition. Those two were never actually great fits to begin with, in my opinion.
Practically, I guess you have to check if your specific compose file parser offer non-standard support for slirp4netns or pasta. If you are using docker-compose (which the podman compose command can use as a plugin), then the answer is no. If you are using podman-compose, then I'll give you a not-very-hopeful "maybe".
I would also recommend that you check out Quadlet. It's podman's native replacement for compose, and will likely support podman-specific features better, not to mention other benefits like better integration with systemd. As far as I understand, it's just a simple parser that takes declarative definition files for containers (and networks, volumes, etc.) and turn them into podman commands with the appropriate arguments.