Skip to main content

Solucionando problemas de configurações de rede privada do Azure para executores hospedados no GitHub em sua organização

Saiba como solucionar problemas comuns enquanto cria configurações de rede privada do Azure para usar executores hospedados pela GitHub com uma VNET do Azure.

Quem pode usar esse recurso?

Os proprietários de organizações em uma empresa podem configurar a rede privada do Azure para executores hospedados pela GitHub no nível da organização.

Troubleshooting configuring private networking for GitHub-hosted runners in your organization

Enabling creation of network configurations for organizations in an enterprise

By default, organizations in an enterprise cannot create new network configurations and only inherit enterprise-level network configurations. Enterprise owners can set a policy that allows organizations in the enterprise to create network configurations that are independent of the enterprise. For more information, see "Configuring private networking for GitHub-hosted runners in your enterprise."

Configuring Azure resources before creating a network configuration in GitHub

Ensure your Azure resources have been configured before adding a network configuration in GitHub.

Supported regions

The GitHub Actions service supports a subset of all the regions that Azure provides. To facilitate communication between the GitHub Actions service and your subnet, your subnet must be in one of the following supported regions.

  • EastUs
  • EastUs2
  • WestUs2
  • WestUs3
  • CentralUs
  • NorthCentralUs
  • SouthCentralUs
  • AustraliaEast
  • JapanEast
  • FranceCentral
  • GermanyWestCentral
  • NorthEurope
  • NorwayEast
  • SwedenCentral
  • SwitzerlandNorth
  • UkSouth
  • SoutheastAsia

Azure private networking supports GPU runners in the following regions.

  • EastUs
  • WestUs
  • NorthCentralUs
  • SouthCentralUs

Azure private networking supports arm64 runners in the following regions.

  • EastUs
  • EastUs2
  • WestUs2
  • NorthCentralUs
  • SouthCentralUs


arm64 runners are currently in beta and subject to change.

If your desired region is not supported, please submit a request for new region availability in this GitHub form. You may also use global virtual network peering to connect virtual networks across Azure regions. For more information, see Virtual network peering in the Azure documentation.

Runner failed to connect to the internet

GitHub-hosted runners need to be able to make outbound connections to as well as other necessary URLs for GitHub Actions.

If GitHub Actions cannot communicate with the runners, the pool will never be able to bring runners online and so no jobs will be picked up. In this case, the pool will have the following error code.


To fix this, ensure that you have configured your Azure resources according to the "Configuring your Azure resources" procedures.

Deployment scope is locked

You can put locks on the Azure subscription or resource group, which can prevent NIC creation or deletion.

Locks that prevent NIC creation fail to pick up jobs, while locks that prevent NIC deletion either exhaust subnet address space (by continuing to create NICs) or have long queue-to-assign (QTA) times as the service retries deployment exceptions.

In this case, the pool will have the following error code.


To fix this, remove the lock or change the subnet you are using to one without a lock.

Deployment blocked by policy

You can create policies on their management group, subscription, resource group, or individual resources. The most common policy is requiring a resource to have certain tags or to have a specific name.

The policy will prevent creation of NICs, which means the pool will not pick up jobs since no VMs can come online.

In this case, the pool will have the following error code.


To fix this, remove the policy or change the subnet you are using to one without a policy.

Subnet is full

Subnets have a limited amount of IP addresses to distribute. Each runner consumes one IP address. If the service attempts to scale up beyond the maximum runner count setting, it will encounter deployment errors.

This impacts the ability of the pool to add additional runners. If the queue depth is high enough, you may experience increased queue-to-assign (QTA) times. Jobs will still be processed, but not at a level of concurrency that you may expect.

In this case, the pool will have the following error code.


To fix this, either increase the size of the subnet you are using or reduce the pool's maximum runner count to match your subnet size.

Incorrect NSG or firewall rules

The "Configuring your Azure resources" procedures list the required openings. However, you may have complex production networks with multiple downstream proxies or firewalls.

If runners are failing to come online, no jobs will be picked up. Your setup process may involve setting up the runner application and communicating back to the GitHub Actions service to indicate it is ready, as well as fetching and installing anti-abuse tooling. If either of these processes fail, the runner cannot pick up any jobs.

If you are experiencing these issues, try setting up a virtual machine on the same subnet that you are using for private networking with GitHub-hosted runners. However, if you have a service association link (SAL) in place, this is not possible.

If you have a SAL in place, try setting up a similar subnet in the virtual network and place a virtual machine on that network. Then attempt to register a self-hosted runner on it.

HTTP request payload failure when configuring Azure resources

While running the command to configure Azure resources, ensure you are using the correct API version and the businessId property. If you are using a different property, your command may return the following error.

(HttpRequestPayloadAPISpecValidationFailed) HTTP request payload failed validation against API specification with one or more errors. Please see details for more information.

If you experience this error, you can see more information by running the command using the ---debug flag.