事象
XServer 上で php artisan schedule:run を Cron に登録して実行したところ、以下のようなエラーが発生し、スケジューラーが正常に動作しない現象が発生しました。
エラー内容
production.ERROR: Undefined constant "CURL_SSLVERSION_TLSv1_2"
{"exception":"[object] (Error(code: 0): Undefined constant \"CURL_SSLVERSION_TLSv1_2\" at ..."}CURL_SSLVERSION_TLSv1_2 定数が未定義のため、Laravel 内部の HTTP 処理で失敗していることがわかります。
原因
このエラーの主な原因は cURL のバージョンが古いこと にあります。
CURL_SSLVERSION_TLSv1_2は PHP 5.5.19 以降で定義されます。- また、cURL ライブラリが 7.34.0 未満 の場合もこの定数が未定義となります。
CLI バージョンの違いに注意
XServer ではドメインごとに PHP バージョンは変更できますが、CLI（コマンドライン）で使用される PHP バージョンは別 です。
CLI 側で古いバージョンが使われている場合、定数が定義されておらずエラーになります。
CLI PHP バージョンの切り替え手順はこちらを参考にしてください：
エラーの直接的な原因
Laravel スケジュール内で Http::get() を使用していたことがトリガーでした。
Laravel では内部的に Guzzle HTTP クライアントが使われており、Laravel 7 以降では TLS1.2 を前提 に動作しています。
そのため、古い cURL 環境では TLS1.2 に対応できず、未定義の定数 CURL_SSLVERSION_TLSv1_2 を参照しエラーとなっていました。
現代の多くの API は TLS1.2 以上を前提としており、暫定的な対処よりも根本対応が推奨されます。
解決方法：XServer の新サーバー環境へ移行
今回の環境は、XServer の 旧サーバー環境（例：sv1 ～ sv16000.xserver.jp） だったため、cURL のバージョンが古く TLS1.2 に対応していませんでした。
対応策
- XServer の新サーバーへ移行（サーバー基盤が最新化され、cURL も新しくなります）
-
これにより
CURL_SSLVERSION_TLSv1_2が定義されるようになり、Laravel の HTTP クライアントも正常動作
実際の移行体験記はこちらにまとめています：
結論
- Laravel + Guzzle 環境で
CURL_SSLVERSION_TLSv1_2エラーが出る場合、cURL や PHP CLI のバージョン確認が最優先 - XServer の場合は、新サーバーへの移行で根本的に解決可能
- セキュリティ的にも TLS1.2 以上が必須な今、対応を後回しにするのは避けましょう
以上