PHP サービス nginx は file_get_contents ソリューションを使用できません-PHPチュートリアル-php.cn

PHP サービス nginx は file_get_contents ソリューションを使用できません

不言

リリース： 2023-04-04 06:30:02

オリジナル

3119 人が閲覧しました

Windows環境にローカル開発サービス環境を構築し、サービスとしてNginxを利用していましたが、file_get_contents()でローカルリンクを取得する際にエラーが発生したため、次の記事で解決方法を紹介します。

1. 問題の内容

Windows環境でローカル開発サービス環境を構築し、サービスとしてNginxを使用していましたが、file_get_contents()を使用してローカルリンクhttp:/を取得すると、 /127.0. 0.1/index.php、そのようなエラーが発生しました:

file_get_contents(http://127.0.0.1/index.php) [<a href=&#39;function.file-get-contents&#39;>function.file-get-contents</a>]: failed to open stream: HTTP request failed!

ログイン後にコピー

ローカルコンピューターの PHP 環境は: nginx php mysql; そこで、この記事を見つけてメモしたので、記録します。

過去 2 日間、私は Windows で nginx fastcgi の file_get_contents リクエストに取り組んできました。多くの学生は、Baidu のページを表示する echo file_get_contents(‘http://www.baidu.com’) など、file_get_contents が外部ネットワーク上の http/https php ファイルをリクエストするときに何のプレッシャーも感じなかったと思います。しかし、localhost/127.0.0.1 ローカルネットワーク上で PHP サービスをリクエストすると、常にタイムアウトが表示され、リクエスト時間とスクリプト実行時間をどれだけ長く設定しても、file_get_contents('http: //localhost/phpinfo.php' )。ただし、htmlなどの静的ファイルをリクエストする場合には全く問題ありません。理由は何ですか？！

まず、file_get_contents/curl/fopen が tcp/ip に基づいて http リクエストを開くと、リクエストデータが nginx に送信され、nginx が php-cgi (fastcgi) に php の処理を委託することがわかります。一般に、fastcgi PHP リクエストを処理した後、すぐに終了シグナルを解除して次の処理リクエストを待ちます (もちろん、プログラムがフリーズしてリソースを占有し続ける場合もあります)。 nginx.conf を開くと、次の行が表示されます:

location ~ .php {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  d:/www/htdocs$fastcgi_script_name;
        include        fastcgi_params;
}

ログイン後にコピー

php で終わるすべてのファイルが fastcgi によって処理されることが明らかにわかりました。また、php.ini 設定ファイルには次の文もあります。 ##

cgi.force_redirect = 1

ログイン後にコピー

は、すべての PHP プログラムが処理のために CGI へのリダイレクトを安全に強制できることを示します。

しかし、Windows では、ローカル 127.0.0.1:9000 はどのようにして php-cgi に接続するのでしょうか? ！答えは、php-cgi プロセスを追加し、それを使用して 127.0.0.1:9000 をリッスンすることです。コントローラーコマンド

RunHiddenConsole.exe D:/www/php/php-cgi.exe  -b 127.0.0.1:9000 -c C:/WINDOWS/php.ini

ログイン後にコピー

を使用して、php-cgi.exe プロセスを開始して、Windows の起動時に 127.0.0.1:9000 からのリクエストをリッスンできます。 dos コマンドで netstat -a を開くと、ローカルコンピューターのポート 9000 が待機状態 (つまり、要求が送信されない場合は空) であることがわかります。

それでは、PHP で file_get_contents()、curl()、および fopen() 関数を使用して localhost にアクセスするときに結果が返されない理由について話しましょう。 file_get_contents('http://127.0.0.1/phpinfo.php') ステートメントを Index.php に追加して、phpinfo.php にリクエストを送信してみましょう。このとき、ブラウザのステータスインジケーターが回転し続け、仕事中です。 Dos で netstat コマンドを開くと、ローカル 9000 ポートのステータスが ESTABLISHED であることがわかり、プロセスがオンラインで処理されていることを示します。実際、ここでは 2 つの http ベースの php リクエストを同時に nginx に送信しています。1 つはindex.php の解析で、もう 1 つは phpinfo.php です。Windows システムは 1 つの http しか読み込まないため、矛盾が生じます。したがって、2 つの php リクエストを同時に処理することはできず、最初のリクエスト (index.php) を最初に処理することしかできず、一方、index.php は phpinfo.php の処理結果を待っており、誰もそれを助けません。 phpinfo.php. リクエストを処理します。これは、index.php が終了シグナルを解放するのを待っているため、プログラムがブロックされ、無限ループに陥ってしまいます。したがって、ブラウザのステータスインジケーターが常に回転していることがわかります。 Curl() と fopen 関数の理由は同じです。

2. 解決策

理由がわかれば、解決策も見つかります。

まず、システムに http リクエストを追加します。別のリクエストが php-cig にロードされると、追加の php リクエストを処理するために他の http を割り当てることができます。現時点では、別のポート (8080 など) を別の http サーバーに割り当てる必要があります。 nginx の場合は次のとおりです。

http {  
    server {  
        listen          80;  
        server_name     127.0.0.1;  
        location / {  
            index index.php;  
            root  /web/www/htdocs;  
        }  
    }  
    server {  
        listen          8080;  
        server_name     127.0.0.1;  
        location / {  
            index index.html;  
            root  /web/www/htdocs;  
        }  
    }  
    include    /opt/nginx/conf/vhosts/php.conf;  
}

ログイン後にコピー

このようにして、ポート 80 と 8080 はそれぞれ次のような異なるプログラムを処理できます。

test.php

 echo file_get_contents('http://localhost:8080/phpinfo.php');

ログイン後にコピー

もちろん、 *unix では fork などの選択肢が増えました。

念のためですが、インターネット上の一部の人は、アドレスの http:// プロトコルマークを削除し、相対アドレスを使用することで機能チェックを回避できると言っていますが、実際はそうなのでしょうか? ！ Index.php で file_get_contents('phpinfo.php'); を使用すると、この関数が phpinfo.php のソースコードを出力することがわかります。これは file_get_contents('file:c:wwwphpinfo.php'); と同等です。実際、上記はテキストコンテンツを読み取るだけです。これは、file_get_contents() 関数が最初にファイルプロトコルを処理し、curl が直接エラーを報告し、解析できないためです。したがって、これらの人々は単に懲りない嘘つきです。

ホストファイルを変更して、関係を暗示するローカルホスト www.xxx.com を追加することを提案する人もいます。この関数は、www.xxx.com を通じてローカル PHP にアクセスします。これは実際には民間療法であり、治癒するものではありません根本的な原因は、コンピュータの DNS 解決を容易にするだけであるため、最終的に www.xxx.com が 127.0.0.1 に引き渡され、後者は依然としてブロックされている唯一の http に引き渡されます。