テクノロジー · 実用ガイド

curl エラー18？再試行・再開前に不足バイトを証明する

CURLE_PARTIAL_FILE は、実際の転送サイズが相手の事前申告と一致しなかったことを示します。部分ファイル、応答ヘッダー、トレースを保存し、フレーミング、プロトコル、中継経路を切り分けてから再取得か検証子付き再開を選びます。

執筆 Watch at Ease News · 3 分で読めます公開 2026/10/18 22:28 UTC

curl エラー18は転送サイズ不一致の証拠であり、単一のネットワーク原因を示す診断名ではありません。curl は CURLE_PARTIAL_FILE を、事前に示されたサイズより短い、または長い転送と定義しています。

最初の部分ファイルを上書きせず、自動再試行もまだ有効にしません。応答フレーミング、受信バイト数、表現の同一性を記録し、サーバー、プロキシ、プロトコル、クライアント経路を一つずつ検証します。

1. 最初の失敗を保存する

部分出力を一意な証拠ファイルへ移し、バイト数とダイジェストを記録します。curl の版と機能、秘密を除いたコマンド、時刻、終了コード、URL、プロキシ経路、ラッパーや CI の有無も保存します。

新しい出力へ一度だけ証拠取得を行い、応答ヘッダーと時刻付きトレースを分離します。Authorization、Cookie、署名付きクエリ、証明書は必ず伏せます。

HTTP/1.1 の最終 Transfer-Encoding が chunked なら、ゼロ長の終端チャンクが必要です。Transfer-Encoding がなく有効な Content-Length がある場合、その値が本文の期待バイト数で、到達前の切断は RFC 9112 上の不完全応答です。

gzip や br は内容符号化、chunked は転送フレーミングです。Accept-Encoding や HTTP 版の変更は原因分岐を比較できますが、誤った長さ、生成処理の停止、中継障害そのものを直すとは限りません。

毎回新しい出力を使い、直結と CDN、IPv4 と IPv6、HTTP/1.1 と HTTP/2/3、圧縮と identity のうち一つだけ変えます。状態、最終 URL、プロトコル、申告長、受信量、終了コード、ダイジェストを記録します。

一経路の成功は別経路の安全を証明しません。オリジン成功・プロキシ失敗なら両方のトレースを残し、全経路が同じ位置で止まるならアプリ、上流タイムアウト、Content-Length 生成、保存装置読み出しを調べます。

200 だけでは不十分です。curl 終了0、フレーミングまたは期待バイト数の完了、公開チェックサム、署名、アーカイブ試験、パーサーなどの完全性確認をすべて要求します。

API では副作用も確認します。非冪等 POST はサーバーで完了後に応答だけ途切れることがあります。再送前に冪等キー、取引 ID、状態 API を確認します。

サーバーが必要な byte range を提供し、ETag や Last-Modified で同一表現を確認できる場合だけ再開します。期待する部分応答と範囲が返ることも確認します。

検証子がない、弱い、変わった場合は新規宛先から開始し、盲目的に追記しません。終了コード、フレーミング、バイト数、完全性が通り、故障経路も修復または除外されて初めて完了です。