Apply IP allow lists and networking settings to runners and troubleshoot runner connectivity and capacity issues.

A self-hosted runner sits inside a corporate network where all outbound HTTPS traffic must pass through an authenticated forward proxy. After registration the runner cannot reach GitHub and stays offline because its connections are not routed through that proxy. The administrator wants the runner application to send its traffic through the proxy without rewriting any workflow. Which configuration directs the runner's outbound connections through the proxy?

# in the runner's .env file
https_proxy=proxy.internal:8080
no_proxy=localhost,127.0.0.1

• ASet the proxy environment variables such as https_proxy and no_proxy for the runner, because the runner application reads them to route its outbound connections through the forward proxy.check_circle Correct
• BAdd a runs-on label named proxy to every job, because that label instructs GitHub to route the dispatched job through the organisation's configured forward proxy before it reaches the runner.
• CAdd a concurrency group to the workflow named proxy, because grouping the runs causes GitHub Actions to funnel the queued jobs through a single proxied connection to the offline runner.
• DStore the proxy address as an organisation secret and reference it in each job, because the runner reads that secret at startup and applies it as its outbound network route automatically.

Why A is correct: The self-hosted runner reads the standard proxy environment variables, so defining https_proxy and no_proxy for the runner sends its outbound traffic through the forward proxy while exempting local addresses.

Why B is wrong: Tempting because labels do steer dispatch, but a label only matches a runner to a job and carries no proxy routing, so the runner's own outbound traffic still bypasses the proxy and fails.

Why C is wrong: Tempting because concurrency governs run scheduling, but it only queues or cancels runs in a group and has nothing to do with how the runner reaches GitHub over the network.

Why D is wrong: Tempting because secrets hold sensitive configuration, but a secret is only injected into a running job's environment, not into the runner service before it connects, so registration still fails.