GitHub in China: Access Checklist for Developers

GitHub in China: Access Checklist for Developers

Jason Chen
September 12, 2026· 9 min read

When GitHub in China fails, name the exact operation before changing anything: loading a repository page, resolving a host, signing in, completing SSO, calling the API, cloning, fetching, or pushing over HTTPS or SSH. These paths use different hosts, protocols, credentials, and organization controls. A green web page does not prove that a push works, and one failed clone does not prove that GitHub is unavailable everywhere.

Key Takeaways:

  • Preserve commits, patches, and untracked files before testing credentials, remotes, or proxy settings.
  • Record the failing command, protocol, host, network, time, and error without publishing tokens or repository data.
  • Compare web, API, HTTPS Git, and SSH separately; do not infer whole-platform availability from one endpoint.
  • Keep TLS verification, SSH host-key checking, SSO, and organization policy intact while diagnosing the route.

This is an operational checklist, not a promise that a service or route is available at every location. Public travel guidance notes that internet access in China can be restricted, while conditions vary by service, provider, place, and time.[1] For a broader first pass, use the mainland China internet checklist; this guide stays focused on GitHub developer workflows.

What is failing when GitHub in China is unavailable?

Build a small failure matrix

Start with a repository you are authorized to use and a non-destructive operation. Do not test by force-pushing, deleting credentials, or repeatedly triggering authentication. Capture enough detail to distinguish the layers.

SurfaceSafe observationWhat a difference suggests
Public web pageDoes the page load fully, partially, or time out?Browser, DNS, TLS, CDN, or network-path issue
Authenticated webCan you sign in and open the intended organization?Identity provider, MFA, SSO, session, or policy issue
HTTPS GitDoes fetch reach the remote and then reject credentials?Transport reached GitHub; authentication or authorization is next
SSH GitDoes connection setup fail before repository authorization?Port, proxy, host verification, or SSH credential issue
APIDoes a documented request return an HTTP response?API host, token scope, rate limit, or policy can differ from web
Another repositoryDoes an authorized public or test repository behave differently?Repository size, LFS, permissions, hooks, or organization policy

GitHub's own connectivity guidance recommends checking the connection, using current GitHub IP information only when needed, and working with the network administrator when a firewall, proxy, or organization network is involved.[2] Do not treat third-party mirrors or copied credentials as diagnostic shortcuts.

1. Preserve local work and record a minimal reproduction

Before changing configuration, confirm that committed work exists locally and copy irreplaceable untracked files to an approved secure location. Record the repository remote with secrets removed, the operation (clone, fetch, pull, push, API call, or browser load), the protocol, the approximate time, and the complete error text. Save the installed Git version and whether Git LFS, submodules, a credential helper, or an enterprise SSO flow participates.

Use a read-only command such as git ls-remote only against a repository you may access. Avoid rapid retries: they obscure timing, can trigger rate or identity controls, and make it harder to compare networks. If the repository contains sensitive names, redact them before sharing a log.

2. Separate browser, DNS, TLS, and service status

Check whether the public GitHub page, sign-in page, repository page, and official status page fail in the same way. A browser extension, cached session, managed certificate, DNS resolver, or captive portal may affect the browser without affecting command-line Git—or the reverse. Compare one private window only if organization policy permits it; do not clear all browser data before preserving useful session and error evidence.

Read the error literally. A name-resolution failure, TCP timeout, TLS certificate error, HTTP proxy response, 403, 404, 429, and 5xx response belong to different layers. Never click through a certificate warning or install an unverified root certificate merely to make the page load.

3. How do you check HTTPS Git without weakening TLS?

Confirm the remote uses the expected https://github.com/OWNER/REPOSITORY.git form and compare it with GitHub's documented clone workflow.[3] If the connection reaches GitHub but authentication fails, review the credential method, token scope, token expiry, SSO authorization, and repository permission. Password authentication for Git operations should not be substituted for the supported credential flow.

Inspect repository, global, and system Git proxy settings separately, plus relevant environment settings, without printing secrets. A stale proxy can affect Git while the browser works. Change one scope at a time and keep a note of the original value. Do not set http.sslVerify=false, suppress certificate validation, or persist a credential in a remote URL.

4. Check SSH as a distinct transport

Verify that the remote host is the intended GitHub host, that the correct key is offered, and that the key is attached to the expected account or organization. Host-key verification is a security boundary: compare the observed fingerprint with GitHub's published fingerprints and stop on a mismatch. Do not delete known_hosts wholesale or enable permissive host checking.

Port 22 may behave differently from HTTPS on a particular network. GitHub documents an SSH-over-HTTPS-port option for networks that block ordinary SSH; follow that official configuration and verify the alternate host key before use.[4] This changes the transport path, not repository permission, SSO, branch protection, signing requirements, or organization policy.

5. Is identity, API scope, SSO, or an organization control blocking you?

Separate authentication from authorization. A valid account session or token may still lack repository access; an organization may require SAML SSO, IP allowlisting, approved OAuth applications, fine-grained token approval, managed-user controls, or a specific SSH certificate. A 404 for a private repository can intentionally conceal its existence.

For API work, record the host, HTTP status, rate-limit headers, token type, and required scope without logging the token. Test the smallest documented read operation. Ask the organization owner or network administrator to confirm policy rather than attempting to route around it. A personal repository result does not prove that an enterprise organization should behave identically.

6. Audit the local proxy and compare one controlled network path

Inventory browser proxy settings, operating-system proxy settings, Git configuration, SSH ProxyCommand or ProxyJump, container or IDE settings, and environment variables. Conflicting layers are common: the web browser may use one path while Git, an IDE extension, or a container uses another. Remove or change only the stale entry you can explain.

If local policy and applicable law permit, compare the same non-destructive operation on one controlled alternative path. A VPN can change the network route, but it cannot restore a GitHub incident, grant repository rights, complete SSO, approve a token, or override employer controls. Keep the command, account, repository, and time window constant so the comparison means something. When that comparison is permitted, AethoVPN can provide the alternative route for the same git ls-remote check.

7. Recover safely and document the working boundary

Apply the narrowest confirmed correction: repair the intended proxy, refresh an approved credential, authorize SSO, ask an administrator to update policy, use GitHub's documented SSH port alternative, or wait for a confirmed incident to resolve. Then repeat the original operation and verify the repository state. For a push, confirm the expected remote commit through an authorized view; absence of an error alone is not proof.

Record which surfaces work, which do not, the network and protocol, the final error or result, and any temporary change that must be reverted. If no path works, preserve the local repository and coordinate an approved handoff, patch transfer, or later retry. Do not upload proprietary code to a public repository or unofficial mirror.

Summary

  • Define the exact GitHub surface and operation before diagnosing availability.
  • Preserve local work and collect a minimal, redacted reproduction.
  • Treat web, API, HTTPS Git, SSH Git, identity, and organization policy separately.
  • Never disable TLS or SSH verification and never bypass employer controls.
  • Verify recovery at the repository level and document the remaining boundary.

FAQ

Is GitHub completely blocked in China?

Do not reduce a changing, path-dependent result to a universal yes or no. Test the exact authorized web, Git, or API operation on the current network and record the date, place, and endpoint.

Why does github.com load while git clone fails?

The browser and Git client can use different protocols, proxy settings, credentials, hosts, and organization controls. Diagnose HTTPS or SSH transport independently from the web page.

Should I disable SSL verification to fix a clone?

No. A TLS error can indicate interception, a wrong clock, a captive portal, a managed certificate problem, or a hostile path. Preserve the error and fix the trust or route issue.

Can I switch from SSH to HTTPS?

Yes, if your repository and organization support it, but the switch changes transport rather than permission. Use the official remote format and an approved credential method.

What if SSH port 22 times out?

Use GitHub's documented SSH-over-HTTPS-port procedure only when permitted, verify the published host fingerprint, and keep strict host checking enabled.

Why does a personal repository work but an organization repository fail?

The organization may require SSO authorization, approved tokens, IP controls, managed identities, or different permissions. Ask its owner or administrator to confirm the intended policy.

Does a VPN guarantee that GitHub push will work?

No. Routing is only one layer; service status, credentials, SSO, repository rights, hooks, branch protection, and organization policy still determine the result.

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

Sources

  1. UK Government, China travel advice, internet access and security: https://www.gov.uk/foreign-travel-advice/china/safety-and-security
  2. GitHub Docs, Troubleshooting connectivity problems: https://docs.github.com/en/get-started/using-github/troubleshooting-connectivity-problems
  3. GitHub Docs, Cloning a repository: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
  4. GitHub Docs, Using SSH over the HTTPS port: https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port

Sources checked 12 September 2026.


Related reading:

Start your 3-day free trial

Sign up to experience all premium features at no cost.

*Available only to new users. Each user is limited to one trial.

GitHub in China: Access Checklist for Developers | AethoVPN