[{"data":1,"prerenderedAt":18},["ShallowReactive",2],{"blog:post:en:configuring-http-proxies-inside-docker-containers":3},{"slug":4,"lang":5,"title":6,"summary":7,"date":8,"tags":9,"tag_slugs":13,"thumbnail_url":14,"translations":15,"body":16,"asset_base":17},"configuring-http-proxies-inside-docker-containers","en","Configuring HTTP Proxies Inside Docker Containers","Route container traffic through an HTTP proxy at build time and runtime, verify the exit IP, and avoid common NO_PROXY mistakes.","2026-11-05",[10,11,12],"docker","proxy","networking",[10,11,12],"https://blog-api.ro-proxy.com/api/blog/posts/configuring-http-proxies-inside-docker-containers/thumbnail.svg?lang=en",[5],"## Why Configure Proxies in Docker Containers\n\nContainers are isolated by default, but they still need outbound network access. A build step may download packages from a public registry. A running application may call external APIs. If the host sits behind a corporate proxy or you route traffic through a proxy gateway, the container does not automatically inherit those settings. Without explicit configuration, apt-get, npm, and HTTP clients inside the container fail with connection timeouts or DNS errors.\n\nThis guide covers how to pass proxy settings into Docker containers at build time and runtime, how to verify that traffic actually leaves through the proxy, and how to keep local traffic from being proxied by mistake.\n\n## Build-Time vs Runtime Proxy Settings\n\nDocker treats proxy configuration in two distinct places:\n\n- Build time: environment variables available during docker build. These affect RUN commands such as package installation.\n- Runtime: environment variables available when the container starts. These affect the application and any outbound requests it makes after launch.\n\nSetting one does not set the other. If your container needs to install packages and then call an API, you usually need both.\n\n### Build-Time Configuration\n\nUse ARG and ENV in the Dockerfile. Pass values with docker build --build-arg.\n\n```\nARG HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\nARG HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\nARG NO_PROXY=localhost,127.0.0.1,.local\n\nENV HTTP_PROXY=$HTTP_PROXY\nENV HTTPS_PROXY=$HTTPS_PROXY\nENV NO_PROXY=$NO_PROXY\n\nRUN apt-get update && apt-get install -y curl\n```\n\nBuild the image:\n\n```\ndocker build \\\n  --build-arg HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT \\\n  --build-arg HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT \\\n  -t my-app .\n```\n\nThe ARG values are not persisted in the final image unless you copy them into ENV. The ENV lines above make them available to RUN and to later stages.\n\n### Runtime Configuration\n\nPass the same variables when you start the container. The application inside can read them directly, or your language runtime may pick them up automatically.\n\n```\ndocker run -e HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT \\\n  -e HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT \\\n  -e NO_PROXY=localhost,127.0.0.1 \\\n  my-app\n```\n\nWith Compose:\n\n```\nservices:\n  app:\n    build: .\n    environment:\n      - HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\n      - HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\n      - NO_PROXY=localhost,127.0.0.1,.local\n```\n\nRoProxy sessions connect through a gateway host on an HTTP port. If you use RoProxy, put that gateway host and port in place of GATEWAY_HOST and HTTP_PORT.\n\n## Verifying the Exit IP\n\nBefore trusting the configuration, confirm that the container reaches the internet through the proxy and not directly. The simplest check is to ask an echo service for the public IP.\n\nInside the container, or through docker exec:\n\n```\ncurl https://api.ipify.org?format=json\n```\n\nTo force the request through the proxy from your host:\n\n```\ncurl -x http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT \\\n  https://api.ipify.org?format=json\n```\n\nCompare the returned IP address with your host's direct IP. If they match, the proxy is not being used. If they differ, traffic is going through the gateway.\n\nIf you get a connection error, check that the gateway host is reachable from the container network and that the credentials are correct.\n\n## NO_PROXY and Internal Traffic\n\nNot every outbound request should go through a proxy. Requests to local services, linked containers, or instance metadata endpoints should usually bypass it. Otherwise, the proxy may try to reach an internal address that it cannot route to, causing timeouts.\n\nAdd exceptions to NO_PROXY:\n\n```\nNO_PROXY=localhost,127.0.0.1,.local,host.docker.internal,.svc.cluster.local\n```\n\nCompose example:\n\n```\nenvironment:\n  - NO_PROXY=localhost,127.0.0.1,.local,host.docker.internal\n```\n\nA common mistake is proxying traffic to a database running on the same host. If localhost is not in NO_PROXY, the application sends the connection to the proxy gateway, which likely has no route back to your local database.\n\n## Complete Example: Node.js Container\n\nHere is a full Dockerfile and Compose file for a Node.js application that installs dependencies at build time and calls an external API at runtime.\n\n```\nFROM node:20-alpine\n\nARG HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\nARG HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\nARG NO_PROXY=localhost,127.0.0.1\n\nENV HTTP_PROXY=$HTTP_PROXY\nENV HTTPS_PROXY=$HTTPS_PROXY\nENV NO_PROXY=$NO_PROXY\n\nWORKDIR /app\nCOPY package*.json ./\nRUN npm ci --omit=dev\nCOPY . .\n\nCMD node index.js\n```\n\n```\nservices:\n  app:\n    build: .\n    environment:\n      - HTTP_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\n      - HTTPS_PROXY=http://USERNAME:PASSWORD@GATEWAY_HOST:HTTP_PORT\n      - NO_PROXY=localhost,127.0.0.1\n```\n\nSome Node.js HTTP clients read proxy variables automatically; others require you to pass the proxy URL explicitly. Check your library's documentation if outbound requests still fail after setting the environment.\n\n## Conclusion\n\nProxy settings in Docker are not inherited from the host. You must pass them explicitly at build time for package installation and at runtime for application traffic. Always verify with curl https://api.ipify.org?format=json, and always exclude local addresses with NO_PROXY. With those three steps, containerized apps can reach external services reliably through an HTTP gateway.\n\nRoProxy sessions can serve as that gateway, with each session using its own username and password. Rotate the session IP through the API when you need a new address, then continue running containers without changing their proxy configuration.\n","https://blog-api.ro-proxy.com/api/blog/posts/configuring-http-proxies-inside-docker-containers/assets",1793951898492]