Proxies

The runner reads the usual proxy variables from its own environment and passes them on to every job:

http_proxy=http://proxy.example:3128
https_proxy=http://proxy.example:3128
no_proxy=gitea.internal,.example.local

Set them where the process is started — Environment= in a systemd unit, docker run -e, or env: in Kubernetes. They are used for the runner’s own requests and are given to jobs in both lower and upper case.

What is exempted automatically

These are added to no_proxy for jobs, so they are always reached directly:

• the cache server
• localhost, 127.0.0.1 and ::1
• the job’s service containers
• the Docker daemon, when it is reached over tcp://

The Gitea instance is not added. Add it to no_proxy yourself if it should be reached directly.

Overriding per job or per runner

Scope	Where to set it
one step	the step’s env:
one job	the job’s container.env
the whole runner	runner.envs in the config; a no_proxy set there is added to the list above instead of replacing it

Setting proxy variables at workflow or job level (outside container.env) has no effect.

The Docker daemon needs its own setting

Images are pulled by the daemon, not by the runner, so the daemon needs its own proxy configuration. In the dind images the daemon shares the container’s environment and picks the variables up; for any other daemon see the Docker documentation. The runner logs a warning at startup when it has a proxy configured and the daemon does not.

Dockerfile actions are built with these variables passed as build arguments, so their RUN steps can reach the network.

Credentials in proxy URLs

A password inside a proxy URL is masked in job logs, but any step can still read it: the step is given the proxy URL in its environment. Prefer a proxy that does not need credentials, or one that authenticates by source address.