PHP cURL脚本Crontab执行报错，SSH手动执行正常问题排查

这种情况我之前踩过不少坑，Cron 和命令行环境的差异几乎肯定是问题所在，咱们一步步来排查：

Cron 的执行环境比你手动登录后的命令行环境简陋太多，很多默认的环境变量（比如 PATH、PHP 的路径）都不一样：

• 别在脚本里直接写 php，改用你通过 which php 拿到的绝对路径，比如把 php your_script.php 改成 /usr/bin/php /full/path/to/your_script.php
• 可以在 Cron 任务里先导出环境变量，或者在 bash 脚本开头导入命令行的环境配置：

  # 在 bash 脚本开头加这行，导入当前用户的环境变量
  source ~/.bashrc
  

• 对比 Cron 和命令行的环境变量：
  先在 Cron 里执行 * * * * * env > /tmp/cron_env.log，然后在命令行执行 env > /tmp/cli_env.log，打开两个文件对比，看 Cron 缺了哪些关键变量（比如 HTTP_PROXY、LD_LIBRARY_PATH）

Cron 默认的工作目录是用户的家目录（比如 /home/your_user），而你手动执行脚本时可能在脚本所在目录，这会导致相对路径失效：

• 脚本里的图片路径、配置文件路径、日志路径全部改成绝对路径，比如把 ./upload.jpg 改成 /var/www/your_project/upload.jpg
• 也可以在 bash 脚本里先切换到脚本所在目录再执行：

  cd /full/path/to/your_script_dir && php your_script.php
  

如果你的上传目标是 HTTPS 服务器，Cron 环境可能因为证书或网络配置失败：

• 给 PHP 的 cURL 请求加上证书路径（Ubuntu 系统默认证书路径是 /etc/ssl/certs/ca-certificates.crt）：

  curl_setopt($ch, CURLOPT_CAINFO, '/etc/ssl/certs/ca-certificates.crt');
  

• 临时关闭 SSL 验证（仅用于测试，生产环境别这么干）：

  curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
  curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
  

• 检查 Cron 用户的网络权限：比如服务器有没有防火墙规则限制 Cron 用户的出站请求，或者命令行里配置的代理在 Cron 里没生效，需要在 Cron 任务里手动设置代理变量：

  HTTP_PROXY=http://your-proxy:port HTTPS_PROXY=http://your-proxy:port /usr/bin/php /path/to/script.php
  

Cron 运行的用户（比如 www-data 或者你的登录用户）可能没有足够的权限访问文件或执行脚本：

• 检查脚本、图片文件的权限：

  ls -l /full/path/to/your_script.php
  ls -l /full/path/to/your_image.jpg
  

  确保 Cron 用户有读权限，必要时用 chmod 或 chown 调整
• 检查 PHP 的 open_basedir 限制：执行 php -i | grep open_basedir（命令行）和在 Cron 里执行 /usr/bin/php -i | grep open_basedir，对比是否限制了脚本或图片的路径

没有日志的排查都是瞎猜，给脚本和 Cron 加上详细日志：

• 在 PHP 脚本里记录 cURL 的错误信息：

  $ch = curl_init();
  // ... 你的 cURL 设置 ...
  $result = curl_exec($ch);
  if(!$result) {
      $error_msg = curl_error($ch);
      error_log("Upload failed: cURL error - {$error_msg}", 3, '/var/log/php_upload_debug.log');
  }
  curl_close($ch);
  

• 把 Cron 的输出重定向到日志文件，方便看错误：

  # Cron 任务里改成这样，把所有输出（包括错误）写到日志
  * * * * * /full/path/to/your/bash.sh >> /var/log/cron_upload.log 2>&1
  

• 查看系统的 Cron 日志：Ubuntu 默认在 /var/log/syslog，用 grep CRON /var/log/syslog 可以看到 Cron 任务的执行状态

Cron 执行的 PHP 可能加载了不同的 php.ini 配置文件：

• 命令行执行 php -i > /tmp/php_cli_info.log，Cron 里执行 /usr/bin/php -i > /tmp/php_cron_info.log
• 对比两个文件里的 curl 扩展配置、error_reporting、open_basedir 等关键参数，看有没有差异

先从环境变量和绝对路径这两个最常见的问题入手，再结合日志慢慢排查，应该很快就能找到原因。

内容的提问来源于stack exchange，提问作者user82887