Package Control 连接超时90%是网络问题，需优先排查DNS、代理、镜像源配置；推荐使用Gitee镜像源并正确填写channel_v3.json路径，或配置http/https_proxy代理，必要时清缓存重装。
Package Control 连接超时，90% 是网络问题，不是 Sublime 本身故障。它本质是个 Python 脚本，依赖系统网络环境发起 HTTPS 请求——国内直连 packagecontrol.io 和 raw.githubusercontent.com 极易失败，超时、SSL 错误、空响应都是表象。
换国内镜像源（最常用、见效最快）
官方源被限，但社区维护的 Gitee 镜像稳定可用，且更新及时。关键不是“能不能用”，而是“用对路径”：
-
channel_v3.json是当前 Sublime Text 4 和较新 ST3（Build 3176+）唯一兼容的格式，旧版channel.json已失效 - 必须写在
Preferences → Package Settings → Package Control → Settings – User中，不是 Settings – Default - 路径必须是完整 HTTPS URL，结尾带
.json，不能漏掉/raw/master/路径段
{
"channels": [
"https://gitee.com/akira-cn/package_control_channel/raw/master/channel_v3.json"
]
}保存后重启 Sublime，再打开 Command Palette（Ctrl+Shift+P）输入 Package Control: Install Package，如果列表能加载出来，说明已生效。
配代理（有科学上网工具时必设）
Clash、V2Ray、Surge 等工具默认监听 127.0.0.1:7890，但 Sublime 的 http_proxy 不会自动继承系统代理，必须显式声明：
-
http_proxy和https_proxy必须都填，且协议统一用http://（即使目标是 HTTPS 站点） -
端口必须与你本地代理软件实际监听端口一致；Clash 默认是
7890，但部分配置可能改成了7891或8080，需确认 - 不要加认证信息（如
user:pass@），Sublime 的 urllib 不支持带认证的代理字符串
{
"http_proxy": "http://127.0.0.1:7890",
"https_proxy": "http://127.0.0.1:7890"
}设完别急着试插件，先在控制台（Ctrl+`）运行：import urllib.request; urllib.request.urlopen('https://packagecontrol.io').getcode()
返回 200 才算真正通了。
手动重装 + 清缓存（当设置无效时兜底）
镜像和代理都设了还失败？大概率是旧缓存或损坏包卡住了。别跳过清理这步：
- 关闭 Sublime Text 完全退出（macOS 注意菜单栏里也要退出，不只是关窗口）
- 删除以下两个位置的残留：
–Installed Packages/Package Control.sublime-package
–Packages/Package Control/文件夹（如果存在） - 去官网 https://www.php.cn/link/befa130dcb31961fa251d61e1e6ba0e1 复制「Simple Installation」里的最新 Python 脚本（注意区分 ST3 / ST4 版本）
- 粘贴进控制台回车执行，看到
Package Control installed或无报错即成功
很多人卡在“看起来安装了，但菜单里没出现”，其实是没删干净旧包，或者脚本复制时多了空格/换行——建议用纯文本编辑器中转一次再粘贴。
hosts 绑定（DNS 污染严重时备用）
如果你发现浏览器能打开 packagecontrol.io，但 Sublime 就是解析失败（报 urllib.error.URLError: ），就是 DNS 污染：
- Windows：用管理员身份运行记事本，打开
C:\Windows\System32\drivers\etc\hosts
macOS/Linux：终端执行sudo nano /etc/hosts - 追加两行（IP 来自最新实测可用节点，非固定）：
50.18.164.171 packagecontrol.io50.18.164.171 www.packagecontrol.io - 保存后刷新 DNS：
Windows 执行ipconfig /flushdns
macOS 执行sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
这招见效快，但 IP 会变，不适合长期依赖；仅用于临时验证是否为 DNS 问题。
真正的难点不在“怎么做”，而在于判断哪一层断了：是 DNS 解析失败？还是 TCP 连接超时？还是 TLS 握手失败？每次失败先看控制台报错类型，再对应选方案——盲目换源或重装，反而掩盖真实瓶颈。
