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.


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.
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.
| Surface | Safe observation | What a difference suggests |
|---|---|---|
| Public web page | Does the page load fully, partially, or time out? | Browser, DNS, TLS, CDN, or network-path issue |
| Authenticated web | Can you sign in and open the intended organization? | Identity provider, MFA, SSO, session, or policy issue |
| HTTPS Git | Does fetch reach the remote and then reject credentials? | Transport reached GitHub; authentication or authorization is next |
| SSH Git | Does connection setup fail before repository authorization? | Port, proxy, host verification, or SSH credential issue |
| API | Does a documented request return an HTTP response? | API host, token scope, rate limit, or policy can differ from web |
| Another repository | Does 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Use GitHub's documented SSH-over-HTTPS-port procedure only when permitted, verify the published host fingerprint, and keep strict host checking enabled.
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.
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 checked 12 September 2026.
Related reading:
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.