“Connection refused”或“cURL error 7”表明请求未发出，根源在系统网络层；需先用ping、curl验证DNS与连通性，再严格配置镜像（键名repo.packagist、type值composer、URL末尾带/）、清缓存并排除代理及属主权限干扰。
Composer 报 “Connection refused”“cURL error 7” 或卡在 TLS handshake，基本就是网络路由不通——不是 Composer 配错了，是系统根本没连出去。
先验证 DNS 和基础连通性
别急着改 composer config，90% 的这类错误跟配置无关，而是系统层就断了：
- 运行
ping packagist.org：返回unknown host就是 DNS 解析失败，立刻换 DNS（比如8.8.8.8） - 运行
curl -v https://mirrors.aliyun.com/composer/：卡在* Connected to是 TCP 建连失败；卡在* TLS handshake是证书、SNI 或中间人拦截 - 企业内网常见静默拦截：用
curl -v https://github.com对比，如果 GitHub 也卡在 TLS，大概率是防火墙策略问题
镜像源必须配对且完整，否则静默 fallback 到官方源
配了镜像却还是走 packagist.org？Composer 不报错也不提醒，只会默默降级。必须同时满足三个硬条件：
- 键名必须是
repo.packagist（不是repos.packagist，也不是repositories.packagist） - 命令末尾必须显式传
composer类型值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（拼路径会变成/composerpackages.json，直接 404）
配完立刻验证：composer config -g repo.packagist 应输出完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
绕过 TLS 校验或强制 IPv4 仅限调试，不能上线
如果确认是 TLS 握手失败（比如公司代理做 HTTPS 中间人），临时验证可用以下命令，但绝不能留在线上环境：
- 禁用 TLS 校验：
composer config -g secure-http false - 跳过 CA 检查：
composer config -g cafile /dev/null（Linux/macOS）或composer config -g cafile C:\cacert.pem（Windows，需提前下载最新cacert.pem） - 强制 IPv4（防 IPv6 路由异常）：
CURL_IPRESOLVE=4 composer install（Linux/macOS）；Windows 可设环境变量set CURL_IPRESOLVE=4后再运行
这些操作只是帮你快速定位是不是路由层的 TLS 或协议栈问题，不是解决方案本身。
缓存和 vendor 权限污染会让重试永远失败
反复执行 composer install 却始终卡在同一处？很可能是缓存或目录归属权被污染：
- 旧失败记录存在缓存里：
composer clear-cache必须做，否则重试照样走原地址 - 之前用
sudo composer install过，vendor/和composer.lock就会被锁死在root名下；检查ls -ld vendor/，若属主是root，执行sudo chown -R $USER: . - CI 环境中建议加
--prefer-dist --no-interaction --no-scripts，跳过 git clone 和钩子脚本，避免卡在非网络环节
网络路由不通的问题，最常被忽略的是“已成功配置镜像，但没清缓存 + vendor 属主是 root”，这两点一叠加，所有重试都白费。
