cron 非交互环境补齐 PATH 与代理变量的配置

cron 任务找不到命令或没有使用代理时，应给任务显式设置完整 PATH，并在任务脚本中 export 客户端支持的代理变量。不要指望它复用当前终端里的 alias、登录脚本和临时 export。以 curl 为例，配置小写 http_proxy、https_proxy 和 no_proxy，再使用绝对脚本路径与明确工作目录，通常能把环境问题从调度问题中分离出来。

我会优先采用“短 crontab 加独立包装脚本”的配方：需要改代理时只改这个任务，不让整个用户的其他定时任务一起受到影响。这是配置取舍，以下示例未在读者机器上执行。

crontab 语法参考：https://man7.org/linux/man-pages/man5/crontab.5.html；curl 官方地址：https://curl.se/；代理变量文档：https://everything.curl.dev/usingcurl/proxies/env.html。本文以 Linux 的用户 crontab 和 curl 为例，其他 cron 实现及客户端应查各自文档。

最小配方：显式 PATH 与绝对脚本入口

# 以下为用户 crontab，不包含运行用户名字段
SHELL=/bin/sh
PATH=/usr/local/bin:/usr/bin:/bin
# 日志目录需提前创建，并允许当前用户写入
*/10 * * * * /bin/sh /opt/report-job/run.sh >> /var/log/report-job/run.log 2>&1

将内容通过当前任务账号的 crontab 编辑入口加入，并保留原有任务。完整 PATH 避免依赖未定义的旧值；不要把这里写成 PATH=$PATH:/opt/tools/bin 并假设环境设置行会像交互 shell 一样展开。需要额外工具目录就写完整路径。注释保持独立一行，不能贴在环境值后面。

这里每十分钟触发一次，仅用于展示。若任务耗时可能超过间隔，还应另行制定防重入方案。系统 /etc/crontab 或 /etc/cron.d/ 条目需要用户名字段，不能直接拿用户 crontab 的行混用。

把任务环境放进包装脚本

先准备 /opt/report-job 工作目录、/opt/report-job/state 输出目录和可写日志目录。下面保存为 run.sh，代理地址与业务 URL 都是占位值，替换后使用。

#!/bin/sh
set -eu
# 固定辅助命令查找范围，不依赖交互终端
PATH=/usr/local/bin:/usr/bin:/bin
export PATH
# 设置本任务的代理，地址为示例占位值
http_proxy=http://proxy.example.net:3128
https_proxy=http://proxy.example.net:3128
no_proxy=localhost,127.0.0.1
export http_proxy https_proxy no_proxy
# 去掉可能造成大小写冲突的继承值
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY all_proxy NO_PROXY
# 相对配置和输出文件统一相对于此目录
cd /opt/report-job
# -q 必须位于首个参数位置，避免默认curl配置干扰
exec /usr/bin/curl -q --fail --silent --show-error \
    --connect-timeout 10 --max-time 60 \
    --output state/latest.json https://api.example.net/report

包装脚本、PATH、工作目录、curl 和日志文件各有职责：PATH 供脚本中的辅助命令使用，绝对路径固定当前 curl 程序，cd 固定文件解释位置，crontab 重定向收集错误。部署前需按实际安装位置替换 /usr/bin/curl。示例最终请求覆盖 latest.json；若输出必须原子替换或保留上次成功文件，应改成临时文件成功后再重命名的业务实现。

exec 让最终进程直接返回 curl 的退出状态；它不创建无限等待的 shell。连接和总耗时限制让网络请求有明确上限。代理账号若需要凭据，不要放进公共示例、任务行或全量环境日志；可用只允许任务账号读取的配置文件承载，并按照客户端支持方式加载。

代理变量按实际客户端解释

curl 的 http_proxy 只接受小写形式；HTTPS_PROXY 等其他协议变量可以有大写形式。为了避免继承环境中同名异值，本配方统一使用小写。https_proxy 的名字对应目标 HTTPS 请求，并不要求代理地址本身必须以 https 开头：示例假设的是 HTTP 代理服务器。

no_proxy 是目标地址的排除列表，命中后该请求不走代理。不要为“保证能访问”随意配置星号，它会使全部目标绕过代理。ALL_PROXY 是未被协议专用配置覆盖时的另一来源，本脚本清理它以明确配置范围。这些结论以 curl 为准，不能推断 Python 库、Java 运行时或其他工具一定遵守同一套规则。

我不建议为了这个任务加载整份 .bashrc。它可能包含交互判断、终端命令与其他项目设置，让依赖再次变得隐蔽。需要 shell 展开的值应放在包装脚本里，并在加载可信配置后显式 export，保证子进程能得到变量。

命令未找到与请求失败分别处理

#!/bin/sh
# 诊断脚本仅输出必要信息，不打印完整环境或代理凭据
printf 'PATH=%s\n' "$PATH"
printf '工作目录=%s\n' "$(pwd)"
command -v curl || exit 127
if [ -n "${https_proxy-}" ]; then
    printf 'https_proxy 已设置\n'
else
    printf 'https_proxy 未设置\n'
fi

可以把这段临时放在包装脚本发请求前，等待一次真实任务后查看日志。它只说明变量是否设置，不能证明代理地址可达或请求一定经过代理。应继续根据 curl 的实际退出状态及受控网络日志判断，不用一张示意图代替运行证据。

可选变体与常见问题

能直接把代理写在 crontab 顶部吗？

可以把非敏感的固定值写成环境设置，但作用范围可能覆盖其后的多个任务。只有一个任务需要代理时，独立脚本更方便管理。

设置 SHELL=/bin/bash 就会加载登录环境吗？

不能据此推断为登录或交互 shell。换解释器解决的是语法兼容，不替代显式任务环境。

手工运行脚本成功，为什么 cron 仍失败？

继续比较任务账号、工作目录、变量是否导出、工具绝对路径及日志写权限。相同脚本名称不代表相同运行上下文。

代理环境里可以直接放完整 env 输出排查吗？

优先打印白名单字段和“是否设置”状态。完整环境可能带认证信息，通常没必要为了判断 PATH 和代理配置把全部变量写入日志。