Do GitHub Actions work in China? There is no single network path: a GitHub-hosted runner executes on GitHub-managed infrastructure, while a self-hosted runner located in mainland China uses that machine's outbound route. First identify the runner and failing step; a queued job, checkout timeout, missing secret, artifact error, or third-party outage needs a different response.

Key Takeaways:

Separate workflow trigger, queue and assignment, runner connectivity, repository checkout, GitHub services, and external dependencies.

A GitHub-hosted result does not measure the developer's local China network; a China-based self-hosted runner does.

Self-hosted runners initiate outbound communication and need approved access to required GitHub endpoints.

Routing cannot fix labels, permissions, secrets, organization policy, billing, workflow syntax, or an unavailable third-party service.

Start with the general mainland service checklist for browser and route baselines. Use the GitHub developer-access checklist for web, API, HTTPS Git, SSH, SSO, and repository access from a workstation. The China VPN guide covers wider network and compliance planning; this guide stays with Actions execution.

Do GitHub Actions work in China, and which runner stage is failing?

Build an execution-path timeline

A workflow must be triggered, accepted, queued, assigned to a matching runner, started, and then complete every network-dependent step. Record the run and job URL, event, commit, runner type, labels, first failing step, timestamps, and sanitized error.

Stage	Evidence	Common non-network explanation
Trigger	Event, branch, filters and workflow version	Path filter, disabled workflow or syntax
Queue	Requested labels, group and wait state	No matching runner, concurrency or plan limit
Runner session	Hosted image or self-hosted identity	Offline service, update or assignment problem
Checkout/services	First host and operation that fails	Token scope, permission or repository state
Workflow command	Exit code and bounded log	Test failure, missing secret or third-party outage

Do not paste secrets, OIDC tokens, private repository names, runner registration tokens, internal endpoints, or full environment dumps into public issues.

1. Identify where the job actually runs

Read runs-on, runner groups, labels, reusable workflows, and any job-routing expressions. A GitHub-hosted runner is a new GitHub-managed virtual machine selected from the requested image; its outbound path is not the browser or laptop path in China. GitHub documents hosted-runner images and their network characteristics separately.［1］

A self-hosted runner runs on infrastructure that its owner deploys and manages.［2］ Record its physical or cloud location, operating system, runner version, service identity, proxy source, labels, group, and whether it is ephemeral. If that host is in mainland China, its own approved outbound path matters.

Do not infer location from the person who clicked “Run workflow.” The execution host, not the operator's browser, performs checkout and later commands.

2. Separate trigger and queue failures from connectivity

Confirm that the intended workflow version exists on the relevant branch and that event, branch, path, environment, and reusable-workflow conditions match. If no run was created, the runner network has not yet participated. If a run exists but a job is skipped, inspect expressions and dependencies.

For a queued job, compare requested labels and runner group with registered runners. Check concurrency, environment approvals, plan or billing limits, organization policy, and whether an administrator disabled Actions or a particular action. A job waiting for a label that no runner has is not a China network failure.

Preserve the queue timestamps before editing labels. Broadening labels may place sensitive code on an unintended runner and is an authorization decision, not a diagnostic shortcut.

3. Verify self-hosted runner assignment and outbound communication

Confirm the runner appears under the intended repository, organization, or enterprise and is allowed for that job. Check the local runner service and bounded diagnostic log without exposing registration credentials. A service can be installed yet offline, stuck updating, assigned elsewhere, or blocked by policy.

GitHub says a self-hosted runner connects outbound to GitHub to receive assignments and download runner updates; inbound GitHub connections are not required for normal operation.［2］ The host must resolve and reach the documented HTTPS endpoints through an approved firewall or proxy. GitHub also warns that some required domains are CNAME targets and that recursive firewall handling may be needed.［2］

Work with the network owner on the current official domain list. Do not disable TLS, accept a mismatched certificate, expose an inbound runner port, or route around organizational inspection controls.

4. Isolate checkout, actions, artifacts, cache, and packages

Once the runner starts, identify the first network-dependent step. Repository checkout can use GitHub API, archive, HTTPS Git, LFS, or submodules depending on configuration. Downloaded actions, release assets, container images, packages, cache, and artifact services can use other hosts. A successful checkout does not prove artifact upload or a container pull will work.

Record the action name and immutable revision, operation, host category, status, timeout, and bytes transferred. Keep third-party marketplace actions and workflow-specific API calls separate from GitHub's own services. An external service outage should not be reported as GitHub Actions availability.

Use the Docker Hub checklist, npm checklist, or PyPI checklist when that ecosystem is the failing step.

5. Check tokens, permissions, secrets, OIDC, and policy

An HTTP response can show that transport reached a service while identity or authorization failed. Inspect the job's declared permissions, repository or organization Actions policy, fork restrictions, environment approvals, secret availability, protected branches, and reusable-workflow secret passing. Do not print token claims or secret values.

OIDC adds a token request and a cloud identity exchange. Separate failure to request GitHub's OIDC token from failure at the cloud provider's issuer, audience, subject, role, or policy check. A route change cannot satisfy an incorrect trust policy.

For private repositories and packages, confirm access belongs to the job identity. Do not copy a personal token onto a self-hosted runner to make the error disappear.

6. Compare a minimal job under controlled conditions

Create or use an approved non-sensitive diagnostic workflow that reports only runner type, timestamps, and success of bounded connections; do not dump environment variables. Hold the commit, workflow, runner labels, account policy, and time window constant. Compare a GitHub-hosted runner and the intended self-hosted runner only if the organization permits both.

If applicable law and policy permit, AethoVPN can supply the controlled alternative route for a self-hosted runner you own: install the Linux (Debian/Ubuntu .deb) or Windows client on that machine, connect to one listed location, and rerun the same minimal job so only the network path changes. It cannot fix a GitHub incident, missing labels, Actions policy, billing, secrets, workflow logic, or a third-party endpoint, and it must not be installed on managed infrastructure without the owner's approval. For a personal test machine, start the 3-day AethoVPN trial before changing runner settings.

The useful result is a narrowed stage: for example, hosted execution succeeds while the China self-hosted runner cannot reach an artifact endpoint. It is not a permanent statement about every GitHub Actions run in China.

7. Verify recovery from trigger to final artifact

Apply only the confirmed correction: restore an approved runner service, fix exact labels, update an authorized proxy or allowlist, correct permissions, pin an action, repair a workflow, or wait for a documented incident. Re-run the same commit and workflow after preserving the original run evidence.

Verify every required job, expected artifact or cache operation, deployment gate, and downstream status rather than stopping at a green first step. For a self-hosted runner, confirm it returns to the expected idle or ephemeral lifecycle and that temporary credentials and workspaces follow organization policy.

Document the runner location, current route, workflow commit, first former failure, final result, and untested endpoints. If the fix depended on a temporary path, assign an owner and expiry rather than leaving an unexplained bypass.

Summary

Identify the runner location and separate triggering, queuing, assignment, and execution.
Map checkout, actions, artifacts, cache, packages, OIDC, and third-party calls separately.
For self-hosted runners, validate approved outbound HTTPS rather than opening inbound access.
Keep tokens, TLS, organization policy, and runner trust intact.
Re-run the same commit and verify all required jobs and artifacts.

FAQ

Do GitHub-hosted runners run through my China connection?

No. They run on GitHub-managed infrastructure. Your local browser may trigger or view the workflow, but the hosted runner performs the job on its own network.

Does a self-hosted runner need an inbound firewall port?

Normally it initiates outbound communication to GitHub. Follow GitHub's current endpoint guidance and the network owner's policy instead of exposing an inbound service.

Why is my job queued but never started?

Check labels, runner groups, offline status, concurrency, approvals, policy, and plan limits. A queued job may not have attempted any external connection.

Why does checkout work but artifact upload fail?

Checkout and artifact services can use different endpoints, tokens, and transfer patterns. Record the first artifact request and its status separately.

Can a VPN fix missing GitHub Actions secrets?

No. Routing cannot create secrets, grant token permissions, approve environments, or change organization policy.

Are GitHub Actions and GitHub website access the same test?

No. The website, Git transport, API, hosted runner, self-hosted runner, and workflow dependencies are separate paths. Use the dedicated GitHub access guide for workstation operations.

How do I prove an Actions runner works from China?

Record the exact runner location and version, workflow commit, trigger, assignment, required service steps, final jobs, and artifacts. State the time and scope rather than claiming permanent availability.

Disclaimer: This article provides general operational and security information, not legal, employer-policy, cloud-architecture, or service-availability advice. Follow applicable law, GitHub's current documentation, and your organization's runner and network controls.

Sources

GitHub Docs, GitHub-hosted runners reference: https://docs.github.com/en/actions/reference/runners/github-hosted-runners
GitHub Docs, Self-hosted runners reference: https://docs.github.com/en/actions/reference/runners/self-hosted-runners

Sources checked 12 September 2026.

Related reading:

Do GitHub Actions Work in China? Runner Checklist