Ooo... That can be a tough one to solve. On the host machine, are you able to access the GemInABox and the npm proxy?
You could run the network_mode: "host" which should bypass the Docker networking and the host's DNS/VPN settings/Proxy config would be available to the container. It also means that you lose the isolation of the containers which means that even without the port forwarding, the application (port 3000) would automatically be exposed on the host machine.
For development, this could be a viable tradeoff as long as you understand the caveats.
Are you using Docker for deploying the application in production? If so, what steps are you using to install the NPM packages and gems from the private gem server? If you want to keep the security isolation, you may need to do something similar.
I went through this kind of hassle in the past where we had multiple dockerfiles and the docker compose commands included one of the "setup" Docker compose files which included stuff like the private certs and accesses to the private repositories. This was used as a build step so the later steps could just copy the installed packages and didn't need to retain the certs and access. It was annoying and often lead to confusions.
I think if I were dealing with something like this today, I may set up something like Tailscale for the developers where their machine could access those resources, or use a build step to do a temporary tailscale connection to install those gems.