快捷導(dǎo)航

PHP Curl出現(xiàn)403錯(cuò)誤的解決辦法

更新時(shí)間：2014年05月29日 10:15:29 作者：

這篇文章主要介紹了PHP Curl出現(xiàn)403錯(cuò)誤的解決辦法,是一個(gè)比較奇葩的錯(cuò)誤,刪除一些CURL的參數(shù)即可解決這個(gè)問題,需要的朋友可以參考下

自己用的小PHP應(yīng)用，使用curl抓網(wǎng)頁下來處理，為了穿墻方便，使用Privoxy作為代理，便于選擇哪些網(wǎng)站使用proxy、哪些不用。但今天卻遇到了奇怪的問題，訪問google baidu這些網(wǎng)站居然都返回403錯(cuò)誤，而訪問其他的一些網(wǎng)站沒事，如果設(shè)置為不使用proxy則都能正常訪問。

難道google baidu就不讓用proxy連接么？顯然不可能，所以打開curl的信息輸出（curl_setopt($this->mSh, CURLOPT_VERBOSE, 1);）看看，得到以下結(jié)果：

復(fù)制代碼代碼如下:

* Trying 127.0.0.1... * connected
* Connected to 127.0.0.1 (127.0.0.1) port 8118 (#0)
* Establish HTTP proxy tunnel to www.baidu.com:80
> CONNECT www.baidu.com:80 HTTP/1.0
Host: www.baidu.com:80
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
Proxy-Connection: Keep-Alive

< HTTP/1.0 403 Connection not allowable
< X-Hint: If you read this message interactively, then you know why this happens ,-)
<
* The requested URL returned error: 403
* Received HTTP code 403 from proxy after CONNECT
* Closing connection #0
... Failed.

可以看到proxy服務(wù)器工作正常，的確是baidu返回了403錯(cuò)誤，但原因肯定還在我這邊。終于，從網(wǎng)上（1of2, 2of2）得到了點(diǎn)啟發(fā)──我使用的是proxytunnel而非proxy。

在代碼中，有這么一句：

復(fù)制代碼代碼如下:

 curl_setopt($this->mSh, CURLOPT_HTTPPROXYTUNNEL, true);
 curl_setopt($this->mSh, CURLOPT_PROXY, $phost);

php文檔中沒有詳細(xì)說明，不過man curl中有詳細(xì)解釋，兩者都是代理，proxytunnel（-p參數(shù)）允許其他協(xié)議通過http代理傳輸，而proxy（-x參數(shù)）則只能走h(yuǎn)ttp協(xié)議。所以我猜測(cè)，google baidu的服務(wù)器和curl的proxytunnel不和，所以返回403。

禁用掉上面2行代碼的第一句后，curl訪問恢復(fù)正常。

比較奇怪的是，幾種操作系統(tǒng)下還不一樣，一臺(tái)MAC OSX就要顯式的禁用proxytunnel才可以，curl版本：

復(fù)制代碼代碼如下:

$ curl --version
curl 7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IPv6 Largefile NTLM SSL libz 

而另外一臺(tái)ubuntu則完全不受影響，怎么都能用，curl版本：

復(fù)制代碼代碼如下:

$ curl --version
curl 7.18.2 (i486-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

MT主機(jī)上的centos也沒事，curl版本：

復(fù)制代碼代碼如下:

$ curl --version
curl 7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps 
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz 

看來不完全是curl版本問題，MAC OSX的確與眾不同啊。

還有一個(gè)原因也會(huì)導(dǎo)致curl返回403錯(cuò)誤，如果設(shè)置了：

復(fù)制代碼代碼如下:

curl_setopt($ch, CURLOPT_NOBODY, true);

則需要緊跟著設(shè)置：

復(fù)制代碼代碼如下:

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'GET');

不然會(huì)因?yàn)閔ttp服務(wù)器不允許 HEAD 命令而返回403錯(cuò)誤。參考：Trouble with a cURL request in PHP（http://forums.devshed.com/php-development-5/trouble-with-a-curl-request-in-php-445222.html）。MAC OSX上curl之所以特殊，也不排除是這種原因吧。

您可能感興趣的文章: