cURL函數庫錯誤碼說明之PHP curl_errno函數

背景概述：
遊戲介面是使用PHP cURL擴充進行請求操作。但是，被請求的伺服器經常會無故的不響應或者逾時。總之，就是請求之後收不到響應回來的資料。這時候可不能說對方API介面有問題，或者，伺服器有故障。總之，可能出現的問題是非常之多。不能一概而論。

一、給出一段常用的PHP cURL代碼：

代碼如下

複製代碼

function sendRequestGame($url) {     $header = array('Expect:');     $ch = curl_init();     curl_setopt($ch, CURLOPT_URL, $url);     curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);     curl_setopt($ch, CURLOPT_HTTPHEADER, $header);     curl_setopt($ch, CURLOPT_TIMEOUT, 10);     curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 10);     $retData = curl_exec( $ch );     curl_close( $ch );     return $retData; }

經常使用PHP cURL函數的人，一定不會陌生吧。

同時，我也相信大部分PHPer也是這樣寫代碼的。至少核心部分就是這樣，根本沒有判斷這個請求失敗了，是什麼情況產生的。

誠然，通過嚴重的安全事故導致我必須重新審核這個cURL庫，該怎樣保證我的請求是穩定可靠的。當出現失敗之後，我要知道是什麼原因導致的。第一時間知道並反饋到人，進行及時的溝通協調與修複。

現在我們為了保證每次請求的穩定可靠性，必須加入日誌功能。即把失敗時請求的相關參數狀態和錯誤碼一起記錄到日誌中。方便，我們失敗之後去檢查。

看代碼：

代碼如下

複製代碼

function sendRequestGame($url) {     $header = array('Expect:');     $ch = curl_init();     curl_setopt($ch, CURLOPT_URL, $url);     curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);     curl_setopt($ch, CURLOPT_HTTPHEADER, $header);     curl_setopt($ch, CURLOPT_TIMEOUT, 2);     curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3);  $return  = curl_exec( $ch );  $errno = curl_errno( $ch );  $info  = curl_getinfo( $ch );  $info['errno'] = $errno;     curl_close( $ch );  $log = json_encode( $info );  putLog( $log );     return $return; } /**  * 打日誌。  * @param string $log 日誌內容。  * @return void  */ function putLog( $log ) {  $log .= "nn";  $logDir = dirname( __FILE__ );  $logPath = $logDir . "/curl_log.txt";  if ( !file_exists( $logPath ) )  {   $handle = fopen( $logPath, 'w' );   fclose ( $handle );  }  file_put_contents( $logPath, $log, FILE_APPEND ); }

現在調用 sendRequestGame 函數的時候，會將每次請求的資訊給json_encode之後儲存到記錄檔 curl_log.txt中。這樣，我們就可以清楚地知道，每次請求到底發生了什麼情況。

改進之後，增加了兩個函數：

$errno = curl_errno( $ch );
$info  = curl_getinfo( $ch );這兩個函數非常的關鍵。第一個 curl_errno是返回當前請求的錯誤碼，0代表沒有錯誤，是一個Ok正常的請求。非0代碼請求出現了錯誤。但是，大部分錯誤發生時，請求都沒有正確到達URL所指定的伺服器。如：主機打不到、網址錯誤、404。當然，不排除有500這種內部伺服器錯誤的存在。

第二個是函數非常重要，curl_getinfo函數會擷取當前請求的相關資訊：

代碼如下

複製代碼

Array (     [url] => http://www.111cn.net/     [content_type] => text/html; charset=UTF-8     [http_code] => 200     [header_size] => 321     [request_size] => 53     [filetime] => -1     [ssl_verify_result] => 0     [redirect_count] => 0     [total_time] => 2.075     [namelookup_time] => 0     [connect_time] => 0.031     [pretransfer_time] => 0.031     [size_upload] => 0     [size_download] => 79042     [speed_download] => 38092     [speed_upload] => 0     [download_content_length] => -1     [upload_content_length] => 0     [starttransfer_time] => 1.388     [redirect_time] => 0     [certinfo] => Array         (         )     [redirect_url] =>

我相信大家人字面意思就能看懂7788.不明白的話，自己去看PHP官方手冊吧。

以下，我再附上 curl error code ，即 curl_errno函數返回的數字說明：
CURLE_UNSUPPORTED_PROTOCOL (1) – 您傳送給 libcurl 的網址使用了此 libcurl 不支援的協議。 可能是您沒有使用的編譯時間選項造成了這種情況（可能是協議字串拼字有誤，或沒有指定協議 libcurl 代碼）。
CURLE_FAILED_INIT (2) – 非常早期的初始化代碼失敗。 可能是內部錯誤或問題。
CURLE_URL_MALFORMAT (3) – 網址格式不正確。
CURLE_COULDNT_RESOLVE_PROXY (5) – 無法解析Proxy 伺服器。 指定的Proxy 伺服器主機無法解析。
CURLE_COULDNT_RESOLVE_HOST (6) – 無法解析主機。 指定的遠程主機無法解析。
CURLE_COULDNT_CONNECT (7) – 無法通過 connect() 串連至主機或Proxy 伺服器。
CURLE_FTP_WEIRD_SERVER_REPLY (8) – 在串連到 FTP 伺服器後，libcurl 需要收到特定的回複。 此錯誤碼表示收到了不正常或不正確的回複。 指定的遠程伺服器可能不是正確的 FTP 伺服器。
CURLE_REMOTE_ACCESS_DENIED (9) – 我們無法訪問網址中指定的資源。 對於 FTP，如果嘗試更改為遠程目錄，就會發生這種情況。
CURLE_FTP_WEIRD_PASS_REPLY (11) – 在將 FTP 密碼發送到伺服器後，libcurl 需要收到正確的回複。 此錯誤碼表示返回的是意外的代碼。
CURLE_FTP_WEIRD_PASV_REPLY (13) – libcurl 無法從伺服器端收到有用的結果，作為對 PASV 或 EPSV 命令的響應。 伺服器有問題。
CURLE_FTP_WEIRD_227_FORMAT (14) – FTP 伺服器返回 227 行作為對 PASV 命令的響應。如果 libcurl 無法解析此行，就會返回此代碼。
CURLE_FTP_CANT_GET_HOST (15) – 在尋找用於新串連的主機時出現內部錯誤。
CURLE_FTP_COULDNT_SET_TYPE (17) – 在嘗試將傳輸模式設定為二進位或 ascii 時發生錯誤。
CURLE_PARTIAL_FILE (18) – 檔案傳輸尺寸小於或大於預期。當伺服器先報告了一個預期的傳輸尺寸，然後所傳送的資料與先前指定尺寸不相符時，就會發生此錯誤。
CURLE_FTP_COULDNT_RETR_FILE (19) – ‘RETR’ 命令收到了不正常的回複，或完成的傳輸尺寸為零位元組。
CURLE_QUOTE_ERROR (21) – 在向遠程伺服器發送自訂 “QUOTE” 命令時，其中一個命令返回的錯誤碼為 400 或更大的數字（對於 FTP），或以其他方式表明命令無法成功完成。
CURLE_HTTP_RETURNED_ERROR (22) – 如果 CURLOPT_FAILONERROR 設定為 TRUE，且 HTTP 伺服器返回 >= 400 的錯誤碼，就會返回此代碼。 （此錯誤碼以前又稱為 CURLE_HTTP_NOT_FOUND。）
CURLE_WRITE_ERROR (23) – 在向本地檔案寫入所收到的資料時發生錯誤，或由寫入回調 (write callback) 向 libcurl 返回了一個錯誤。
CURLE_UPLOAD_FAILED (25) – 無法開始上傳。 對於 FTP，伺服器通常會拒絕執行 STOR 命令。錯誤緩衝區通常會提供伺服器對此問題的說明。 （此錯誤碼以前又稱為 CURLE_FTP_COULDNT_STOR_FILE。）
CURLE_READ_ERROR (26) – 讀取本地檔案時遇到問題，或由讀取回調 (read callback) 返回了一個錯誤。
CURLE_OUT_OF_MEMORY (27) – 記憶體配置請求失敗。此錯誤比較嚴重，若發生此錯誤，則表明出現了非常嚴重的問題。
CURLE_OPERATION_TIMEDOUT (28) – 操作逾時。 已達到根據相應情況指定的逾時時間。 請注意： 自 Urchin 6.6.0.2 開始，逾時時間可以自行更改。 要指定遠程日誌下載逾時，請開啟 urchin.conf 檔案，取消以下行的注釋標記：
#DownloadTimeout: 30
CURLE_FTP_PORT_FAILED (30) – FTP PORT 命令返回錯誤。 在沒有為 libcurl 指定適當的地址使用時，最有可能發生此問題。 請參閱 CURLOPT_FTPPORT。
CURLE_FTP_COULDNT_USE_REST (31) – FTP REST 命令返回錯誤。如果伺服器正常，則應當不會發生這種情況。
CURLE_RANGE_ERROR (33) – 伺服器不支援或不接受範圍請求。
CURLE_HTTP_POST_ERROR (34) – 此問題比較少見，主要由內部混亂引發。
CURLE_SSL_CONNECT_ERROR (35) – 同時使用 SSL/TLS 時可能會發生此錯誤。您可以訪問錯誤緩衝區查看相應資訊，其中會對此問題進行更詳細的介紹。可能是認證（檔案格式、路徑、許可）、密碼及其他因素導致了此問題。
CURLE_FTP_BAD_DOWNLOAD_RESUME (36) – 嘗試恢複超過檔案大小限制的 FTP 串連。
CURLE_FILE_COULDNT_READ_FILE (37) – 無法開啟 FILE:// 路徑下的檔案。原因很可能是檔案路徑無法識別現有檔案。 建議您檢查檔案的存取權限。
CURLE_LDAP_CANNOT_BIND (38) – LDAP 無法綁定。LDAP 綁定操作失敗。
CURLE_LDAP_SEARCH_FAILED (39) – LDAP 搜尋無法進行。
CURLE_FUNCTION_NOT_FOUND (41) – 找不到函數。 找不到必要的 zlib 函數。
CURLE_ABORTED_BY_CALLBACK (42) – 由回調中止。 回調向 libcurl 返回了 “abort”。
CURLE_BAD_FUNCTION_ARGUMENT (43) – 內部錯誤。 使用了不正確的參數調用函數。
CURLE_INTERFACE_FAILED (45) – 介面錯誤。 指定的外部介面無法使用。 請通過 CURLOPT_INTERFACE 設定要使用哪個介面來處理外部串連的來源 IP 位址。 （此錯誤碼以前又稱為 CURLE_HTTP_PORT_FAILED。）
CURLE_TOO_MANY_REDIRECTS (47) – 重新導向過多。 進行重新導向時，libcurl 達到了網頁點擊上限。請使用 CURLOPT_MAXREDIRS 設定上限。
CURLE_UNKNOWN_TELNET_OPTION (48) – 無法識別以 CURLOPT_TELNETOPTIONS 設定的選項。 請參閱相關文檔。
CURLE_TELNET_OPTION_SYNTAX (49) – telnet 選項字串的格式不正確。
CURLE_PEER_FAILED_VERIFICATION (51) – 遠程伺服器的 SSL 憑證或 SSH md5 指紋不正確。
CURLE_GOT_NOTHING (52) – 伺服器未返回任何資料，在相應情況下，未返回任何資料就屬於出現錯誤。
CURLE_SSL_ENGINE_NOTFOUND (53) – 找不到指定的加密引擎。
CURLE_SSL_ENGINE_SETFAILED (54) – 無法將選定的 SSL 加密引擎設為預設選項。
CURLE_SEND_ERROR (55) – 無法發送網路資料。
CURLE_RECV_ERROR (56) – 接收網路資料失敗。
CURLE_SSL_CERTPROBLEM (58) – 本地用戶端認證有問題
CURLE_SSL_CIPHER (59) – 無法使用指定的密鑰
CURLE_SSL_CACERT (60) – 無法使用已知的 CA 憑證驗證對等認證
CURLE_BAD_CONTENT_ENCODING (61) – 無法識別傳輸編碼
CURLE_LDAP_INVALID_URL (62) – LDAP 網址無效
CURLE_FILESIZE_EXCEEDED (63) – 超過了檔案大小上限
CURLE_USE_SSL_FAILED (64) – 請求的 FTP SSL 層級失敗
CURLE_SEND_FAIL_REWIND (65) – 進行發送操作時，curl 必須迴轉資料以便重新傳輸，但迴轉操作未能成功
CURLE_SSL_ENGINE_INITFAILED (66) – SSL 引擎初始化失敗
CURLE_LOGIN_DENIED (67) – 遠程伺服器拒絕 curl 登入（7.13.1 新增功能）
CURLE_TFTP_NOTFOUND (68) – 在 TFTP 伺服器上找不到檔案
CURLE_TFTP_PERM (69) – 在 TFTP 伺服器上遇到許可權問題
CURLE_REMOTE_DISK_FULL (70) – 伺服器磁碟空間不足
CURLE_TFTP_ILLEGAL (71) – TFTP 操作非法
CURLE_TFTP_UNKNOWNID (72) – TFTP 傳輸 ID 未知
CURLE_REMOTE_FILE_EXISTS (73) – 檔案已存在，無法覆蓋
CURLE_TFTP_NOSUCHUSER (74) – 運行正常的 TFTP 伺服器不會返回此錯誤
CURLE_CONV_FAILED (75) – 字元轉換失敗
CURLE_CONV_REQD (76) – 調用方必須註冊轉換回調
CURLE_SSL_CACERT_BADFILE (77) – 讀取 SSL CA 憑證時遇到問題（可能是路徑錯誤或存取權限問題）
CURLE_REMOTE_FILE_NOT_FOUND (78) – 網址中引用的資源不存在
CURLE_SSH (79) – SSH 會話中發生無法識別的錯誤
CURLE_SSL_SHUTDOWN_FAILED (80) – 無法終止 SSL 串連