网络手记
命令里没写重试却反复请求？用 curl -q 检查默认配置
复制了一条简短命令，实际请求却发生了意外的重试、代理或跳转行为，原因可能在命令之外。排查前先确认：curl 除了显式参数，还可能读取默认配置和环境信息。
本文针对 curl.exe 的调用边界，不保证一次正常请求就能证明机场恢复。
示意图：-q 跳过默认配置读取，其他输入来源仍需单独核对。
-q 能排除什么
根据 curl 官方手册，-q 或 --disable 必须放在第一个命令参数，才能关闭默认 curl 配置文件的读取。
它不等于“清空全部网络设置”。你显式传入的 --config、命令参数以及适用的环境代理变量仍需分别核对。也不要把 -q 放在命令末尾后，误以为已经完成同样的对照。
先运行一条参数明确的只读请求
curl.exe -q --show-error --max-time 20 --output NUL --write-out "HTTP:%{http_code}\n" https://example.com/
$requestExit = $LASTEXITCODE
$requestExit
示例只发一次小型公开 GET，没有账号凭据，也没有指定自动重试或跟随重定向。环境代理可能仍然生效；如果要判断真实出站路径，还需结合当前客户端的接管设置。
不要为了比较而先执行一个内容未知的默认配置。它可能包含你已忘记的认证、文件输出或其他操作选项。已有异常请求记录可作为线索，先阅读本机配置，再决定如何恢复需要的参数。
按来源拆解意外行为
- 显式参数。 检查脚本、函数或命令封装最终传入了什么参数，是否存在
--retry、--location、--proxy或--config。 - 默认配置。 按 curl 手册中与你系统匹配的配置文件规则找到文件，只在本机查看。记录相关选项名称，不把整份配置粘到工单。
- 环境信息。 查看程序启动环境是否配置代理变量。
-q并不承诺忽略它们。 - 逐项重建。 在这条参数明确的公开 GET 上，每次只添加一个确认需要的选项，观察意外行为从哪一步重新出现。
读取配置时尤其注意其中的凭据或私人 URL。对外说明“存在某个选项”通常已经足够，不需要把值全部公开。
怎样确认排查有效
保留原问题现象、对照命令、时间、退出码和最终生效的选项来源。如果只知道“加 -q 好了”，仍需确认是哪项默认设置改变了行为；这只能定位请求工具的配置边界，不是对机场推荐名单或全部节点可用性的证明。
确认需要的设置后，可继续在个人脚本中显式表达必要参数，使下一次请求能够复查。这里的对照流程只用于公开 GET，不用于反复提交付款、上传或写入操作。
来源与核验日期
官方资料核验日期：2026-10-05。文中的表格和流程用于自行检查，不代表本站对某家机场的实测结论。
评论