适用条件与问题边界
更换 Clash 电脑端本地代理端口之后，Git 不会去读 Clash 的全局配置，也不会自动改写自身保存的代理键。手册里的全局配置只说明内核怎样开放代理端口，包括是否允许其他设备经过该端口访问互联网、绑定哪些地址、哪些地址段可以连接、哪些地址段被禁止，以及 http(s)、socks、mixed 代理如何做用户验证。清理旧 Git 设置的适用条件是：本机 Git 曾经把该代理端口当作访问远程仓库的出口，并且端口、绑定地址或鉴权已经发生变化。若只是仓库认证过期或远程服务端限制，不属于本题范围。
可以用三条依据判断是不是旧设置残留。第一，Git 提示无法连接代理，但内核在当前日志级别下没有任何入站记录，说明请求没有打到现在的代理端口。第二，请求已经进入内核，却被地址段策略拒绝，应查看禁止连接的地址段；文档写明黑名单优先级高于白名单。第三，已经连上代理端口但要求提供用户名密码，应核对本机地址是否位于允许跳过验证的前缀中；文档示例包含本机回环的 IPv4 与 IPv6 网段。绑定地址从全部地址改成单个 IPv4 或单个 IPv6 时，Git 仍指向回环可能导致完全连不上，这时要同时改地址，而不是只改端口数字。不要把外部控制 API 的监听端口写进 Git。
清理步骤
先只记录 Clash 侧当前事实：代理端口、绑定地址、是否允许局域网、允许与禁止的地址段、是否启用用户验证、哪些前缀可以跳过验证。新端口尚未开始监听时不要先改 Git，否则无法区分旧值残留和新端口未生效。电脑端若同时开着多个终端，每个终端的环境变量可能不同，记录时要写明是在哪一个会话里操作。
然后按系统级、全局级、仓库级列出 Git 里所有代理相关键，并用能够显示来源文件的方式确认路径。同一键出现多层时，更靠近仓库的配置通常覆盖全局。还要检查进程环境中的代理变量及其小写形式，它们不会因为修改 Git 配置文件而消失。判断依据是：文件已经没有旧端口，但命令行仍然失败，则旧值多半在环境变量或另一份更近的配置里。
接着删除所有指向旧端口的键。若该环境仍需要经过 Clash，再写入与当前绑定地址和端口一致的新值。若启用了用户验证且 Git 所在地址不在跳过前缀中，新的代理定位必须带上用户名和密码；若本机已在跳过前缀中，不要把过期账密留在 Git 里，以免把认证失败误判成端口问题。完成后再做一次不依赖图形界面名称的远程列举或获取，并把日志级别调整到能够输出一般运行内容或尽可能详细的信息。官方级别包括静默、仅严重错误、警告、一般信息与尽可能详细。无入站日志就继续清环境变量；出现认证失败就回到用户验证与跳过前缀；地址族不符则检查是否允许 IPv6 以及绑定地址是否覆盖 Git 实际使用的协议族。
失败时的下一步
如果取消设置之后仍然走向旧端口，继续查找集成开发环境自带的 Git 可执行文件、用户级与系统级环境变量，以及是否有包装脚本在启动时写回代理。进程匹配模式即使开到强制匹配全部进程，也不会改写 Git 配置，它只决定内核要不要识别进程。运行模式如果是全局直连，出站路径会被改变，不能和旧代理定位未清理混为一谈。TCP 并发、Keep Alive 间隔、空闲时间与是否禁用 Keep Alive 只影响连接如何建立和探测，并不负责删除 Git 里的旧值。仍然无法判断时，把日志级别升到尽可能详细，并确保同一时刻只有一处代理定义生效。若绑定地址或禁止地址段本身拒绝了本机，应先改全局配置中的地址策略，而不是反复清理 Git。