你刚解决了一个路径被 MSYS 悄悄改写的问题，办法是给命令加上 MSYS_NO_PATHCONV=1。命令不再乱改参数了，但这次它换了个姿势报错，报的还是个看起来像网络故障的错误。
现象
命令输出：
curl: (23) client returned ERROR on write
这个错误码 (23) 和「write」（写入）有关，字面上非常像「网络写失败」，于是你很自然地去查网络、查代理、查防火墙。查了半天发现网络一点问题没有。
根因
这条是一条**「修之前那条坑时引入的新坑」**，也就是上一步的副作用。
回顾一下：你为了阻止 MSYS 改写以 / 开头的参数，加了 MSYS_NO_PATHCONV=1。但 MSYS_NO_PATHCONV=1 是全局、一刀切的——它把这一次命令里所有的路径转换都关掉了。
而你的命令里恰好有这一句：
curl -o /dev/null https://example.com/large-file
-o /dev/null 的意思是「把下载内容丢到 /dev/null，也就是丢弃，不写盘」。在正常的 MSYS 环境里，/dev/null 会被 MSYS 自动转换成 Windows 的 NUL 设备，所以「丢弃」这个动作能正常完成。
但一旦你开了 MSYS_NO_PATHCONV=1，这个转换就没了。/dev/null 被原样交给 curl，而 Windows 上没有 /dev/null 这个路径，curl 尝试往一个不存在的位置写数据，失败了——于是报 (23) client returned ERROR on write。
所以这个错误和网络完全无关，是「写入目标无效」被错误地翻译成了看起来像网络问题的样子。
解决
不要在开了 MSYS_NO_PATHCONV=1 的场合使用 /dev/null。换一个「丢弃输出」的方式：
-
用 Windows 的
NUL设备：MSYS_NO_PATHCONV=1 curl -o NUL https://example.com/large-file -
或者干脆写到一个临时文件，用完再删：
MSYS_NO_PATHCONV=1 curl -o /tmp/discard.bin https://example.com/large-file rm -f /tmp/discard.bin -
如果这条命令本身不需要禁用路径转换，那就别加
MSYS_NO_PATHCONV=1——把它限定在真正需要的那条命令上，而不是整条链路。
更讲究的做法是缩小影响范围：MSYS_NO_PATHCONV=1 只用在「那个参数确实会被改写」的那一次调用上；其它命令保持默认。别图省事把它设成全局环境变量 export 出去，否则所有依赖路径转换的东西都会跟着坏。
延伸与预防
这条坑的教训不是某个具体命令，而是一种思维方式：
修一个坑的时候，要留意它有没有在下游制造新坑。
很多「修复」不是消除问题，而是把问题从一个地方挪到另一个地方，甚至引入一个更隐蔽的新问题。所以每次改完，都要问一句：
- 这个改动影响了多大范围？是局部的还是全局的？
- 被它影响到的其它东西，原本依赖的行为还在不在？
- 我这次「修好」的验证，有没有覆盖到可能被波及的部分？
具体到这一类「开关」性质的参数（MSYS_NO_PATHCONV 是这样，很多 --no-xxx 的开关也是），它们通常有一个共同特征：关掉某个便利功能的同时，也关掉了所有依赖这个功能正确工作的地方。 便利功能之所以存在，是因为有东西在依赖它；一刀切地关掉，依赖它的地方就裸奔了。
还有一个顺带的操作教训：遇到报错别只看文字。client returned ERROR on write 看起来是网络，其实是文件系统；错误码和描述是程序按自己的视角写的，未必和你以为的那一层对应。先确认「这个错误到底发生在哪一步」，再动手。