总览/ 课程地图/ S0 起手式

M03本地环境与网络通道

所属路径 A / B / C 第 3 / 31 讲 S0 起手式

GitHub 访问不稳时，这台机器到底能不能推代码

学完能在访问不稳的网络里 10 分钟内给出「能推 / 只能读 / 都不行」的结论

01为什么重要

本机推不上 GitHub，九成不是网速问题，是通道问题。三条通道稳定性不同，而且「curl 通」和「能推送」是两件事——前者只证明网络可达，后者还要求凭据正确。

02要讲清的 4 件事核心要点

Node / Python / Git 的版本与 PATH 优先级
三条通道按稳定性排序：SSH:22 最稳 → ssh.github.com:443 备用 → HTTPS:443 最不稳
先测通道再谈报错：443 能通不等于能推，判据是 push --dry-run 的退出码
代理变量 http_proxy / https_proxy 如何影响 git 与 curl

03照着做：4 步操作顺序

记录 git / node 的版本与 PATH 顺序
依次测 HTTPS:443、SSH:22、ssh.github.com:443
看 git push --dry-run 的退出码，不看状态码
把可用通道与结论写进体检报告

ssh -T git@github.com
git push --dry-run; echo "rc=$?"
ssh -T -p 443 git@ssh.github.com

04产出物与验收做完怎么算过

产出物

《本机通道体检报告》

验收判据

可验git push --dry-run 得到明确退出码（0 为通）

人评能解释为什么是这个结论

05练习15 分钟内可做完

分别用 HTTPS、SSH:22、ssh.github.com:443 各推一次空提交，记录三条通道的成败与耗时，排出你自己的可用顺序。

06最容易踩的坑

只看 443 能通就断言可用——网络可达不等于有凭据；PowerShell 吞输出，排障改用 Bash

后果：把 curl 返回 200 当成「能推」，然后在一个没有凭据的仓库上耗掉半天。

07自检表进度存在本机浏览器

0 / 7

步骤我已完成：记录 git / node 的版本与 PATH 顺序
步骤我已完成：依次测 HTTPS:443、SSH:22、ssh.github.com:443
步骤我已完成：看 git push --dry-run 的退出码，不看状态码
步骤我已完成：把可用通道与结论写进体检报告
验收我能用命令证明：git push --dry-run 得到明确退出码（0 为通）
验收我能讲清：能解释为什么是这个结论
避坑我确认没有出现：只看 443 能通就断言可用——网络可达不等于有凭据；PowerShell 吞输出，排障改用 Bash

08本讲术语全部 28 条

dry-run：试运行：命令完整走一遍但不真正生效，用来验证权限与路径（如 git push --dry-run）。