Problem: GitHub direct connection is slow/fails (clone reset, port 443 unreachable, SSH auth, release downloads interrupted) —— Trove problem library

What you will run into

Every GitHub-dependent flow is unstable on direct connections from China: git clone of a large repo hangs at "Cloning repository" then resets; plugin/skill CLI installs report port 443 unreachable; marketplace clones fail with SSH authentication errors;

Release assets (deb/AppImage) keep dropping mid-download.

The errors look unrelated, but there are only three layers: network (unstable direct link), config (git rewrite rules / dead proxy), credentials (SSH key / gh token state). Diagnose by layer first — don't try random fixes against the error text.

Why this happens

Key insight: public repos are reachable anonymously over HTTPS — no credentials needed. If a public repo reports a "permission" error, suspect config and credentials first, not the network.

The three layers are three independent chains: the network layer is physical reachability of TCP/TLS to github.com and objects.githubusercontent.com — when domestic egress is unstable, connections get reset at the transport layer, unrelated to your command;

the config layer is "addressing rewrites" — insteadOf rewrites HTTPS to SSH and a leftover http.proxy points requests at a dead proxy, applied before any remote access;

the credential layer is "authentication state" — SSH keys, gh tokens, and account status decide whether non-public access is accepted.

The layers are serial: reachability first (network), then addressing per config, then credential auth — which fixes the diagnostic order from the bottom up: curl first to test the network, then insteadOf/proxy, then credentials.

When a public repo reports a "permission error", the network layer is already ruled out (you must be connected to reach authentication), so the problem can only be in the config or credential layer.

Step by step

1. Diagnose by layer — Required (30s, decides which path)

curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 https://github.com/

• Timeout / 000 → network layer, go to step 2;
• 200 / 301 → network is up, continue:

GIT_CONFIG_GLOBAL=/dev/null git ls-remote https://github.com/octocat/Hello-World.git

• Refs listed → config/credentials confirmed, go to step 4;
• Also fails → the network layer throttles/drops git traffic, go to step 2.

2. Network layer: switch channels — Per diagnosis (network layer hit only)

Three channels by availability (market-probed 2026-08-28~30):

# a) gh-proxy prefix (13.5MB Release asset in seconds, tested)
curl -L -o pkg.deb "https://gh-proxy.com/https://github.com/<owner>/<repo>/releases/download/<tag>/<asset>"

# b) codeload tarball (544K / 2.1s stable, tested)
curl -sL https://codeload.github.com/<owner>/<repo>/tar.gz/refs/tags/<tag> | tar xz

# c) explicit proxy (when you have one)
git config --global http.https://github.com.proxy http://127.0.0.1:<port>

tarball downloads failing → switch to a shallow clone (git clone --depth 1); clones failing → switch to tarball. Swapping often bypasses a bad path. Off-peak retries and switching networks (mobile hotspot often works) also help.

SSH over 443 (official channel: way out when SSH itself is blocked)

If port 22 is unreachable but your SSH key is fine, GitHub officially supports SSH over port 443 (the HTTPS port) — most firewalls allow 443 while blocking 22.

# 1) Probe the 443 channel (the hostname is ssh.github.com, NOT github.com)
ssh -T -p 443 git@ssh.github.com
# Success output: Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access.

# 2) One-off use: clone via this address directly
git clone ssh://git@ssh.github.com:443/<owner>/<repo>.git

# 3) Permanent: write ~/.ssh/config
Host github.com
    Hostname ssh.github.com
    Port 443
    User git

The first connection warns The authenticity of host '[ssh.github.com]:443 ...' can't be established — that's the normal known_hosts warning for a new hostname; answer yes only after matching the fingerprint against GitHub's published ED25519 fingerprints.

Two caveats: GitHub Enterprise Server does not support this channel; an explicit proxy may interfere with the 443 channel (with a proxy, prefer the gh-proxy approach above).

3. Network layer: install scenarios — use paths that don't depend on GitHub — Per scenario (install flows)

• Just want the tool: pip install <pkg> (Tsinghua mirror -i https://pypi.tuna.tsinghua.edu.cn/simple) — no need to clone source;
• Skills/plugins: unpack the tarball and copy into place (e.g. cp -r agent-skills-0.6.7/skills ~/.claude/skills/);
• Judge success by the artifact (directories/files in place), not the exit code (some CLIs return 0 on failure).

4. Config layer: check rewrite rules and stale proxy — Per diagnosis (config layer hit only)

git config --global --get-regexp 'url\..*\.insteadof'   # url.git@github.com:.insteadof = culprit
git config --global --list | grep -i proxy               # leftover proxy check
git config --global --unset-all "url.git@github.com:.insteadof"
git config --global --unset http.proxy
git config --global --unset https.proxy

5. Credentials: SSH and the gh credential helper — Per diagnosis (credentials hit only)

git ls-remote git@github.com:<owner>/<repo>   # Permission denied (publickey) = SSH-layer problem
git config --global url."https://github.com/".insteadOf "git@github.com:"   # force HTTPS (public repos are anonymous)
gh auth status                                # credential helper state
gh auth logout && gh auth login               # re-authorize

6. Verify downloads after fetching — Required (finish)

du -h pkg.deb        # compare with the asset page size; much smaller = partial, re-download
dpkg-deb -I pkg.deb >/dev/null && echo DEB-OK   # readable structure = complete (deb)

Variant quick reference (8 same-root entries merged)

How to confirm it works

• Network layer: the original command (clone/download/install) completes with no reset by peer / Timed out; downloads match the asset page size.
• Config layer: GIT_CONFIG_GLOBAL=/dev/null git ls-remote https://github.com/octocat/Hello-World.git lists refs; rewrite rules and stale proxy removed.
• Credentials: public repos clone over anonymous HTTPS; SSH scenarios no longer report Permission denied; when port 22 is blocked, ssh -T -p 443 git@ssh.github.com authenticates successfully.- Credentials: public repos clone over anonymous HTTPS; SSH scenarios no longer report Permission denied.
• Installs: judge by the artifact in place, not the exit code.

Other environments

Symptom

• git clone hangs at Cloning repository then Connection reset by peer / timeout;
• Failed to connect to github.com port 443;
• SSH authentication failed / Permission denied (publickey);
• Public repos also report Please make sure you have the correct access rights and the repository exists;
• Release / zip / tarball downloads keep dropping, TLS interruptions;
• Some CLIs return exit code 0 on failure (trap).

Cause

The direct link to GitHub from China is unstable (Release assets additionally go through objects.githubusercontent.com, a worse path); HTTPS→SSH global rewrite rules and stale proxies from old tutorials amplify it; abnormal SSH key / gh credentials / account state blocks even public repos.

Solution

1. Diagnose by layer: curl https://github.com/ + GIT_CONFIG_GLOBAL=/dev/null git ls-remote to separate network/config/credentials;
2. Network layer channel swap: gh-proxy prefix, codeload tarball, shallow clone, explicit proxy, off-peak/network switch; when SSH itself is blocked, use the official 443 channel (ssh.github.com);2. Network layer channel swap: gh-proxy prefix, codeload tarball, shallow clone, explicit proxy, off-peak/network switch;
3. Install scenarios use GitHub-free paths: pip with Tsinghua mirror, tarball manual copy; judge by artifact not exit code;
4. Config layer: remove rewrite rules and stale proxy; credentials: force HTTPS / re-auth gh;
5. Verify downloads by size/structure.

Related canonicals

Read as same root (unstable egress at the network layer, mirror family):

• pip install timeout/slow (same network layer, PyPI mirrors)
• npm install slow/hang (same network layer, npm mirrors)
• Go module fetch slow/timeout (same network layer, Go proxy config)
• docker pull fails/mirror (same network layer)
• Only one specific website won't open (layer diagnosis) (same layering idea: locate the network layer with curl first)

Similar errors but different root cause: TLS/certificate issues.

References

• GitHub Docs: Using SSH over the HTTPS port — <https://docs.github.com/en/authentication/troubleshooting-ssh/using-ssh-over-the-https-port>