Webサーバー（Apache/Nginx）は、要求しているユーザーエージェントの要求された場所に基づいて（$_SERVER['REMOTE_ADDR']）を提供しています。だから私は彼らが嘘をついているかもしれないと理解していますが、この値が空白になる可能性はありますか？ネットワークインタフェースまたはWebサーバは、正しく形成されたIPなしで要求を受け付けることすらできますか？REMOTE_ADDRが空白になる可能性はありますか？
http://php.net/manual/en/reserved.variables.server.php
httpサーバまたは少なくとも対応するPHP SAPIまでは、理論上は可能です。
実際には、CLI SAPIを除いて、このような状況には遭遇していません。
EDIT：Apacheの場合は、ap_add_common_varsが常にApacheモジュールPHP SAPIによって読み込まれるテーブルに追加されるため、常に設定されているように見えます（免責事項：Apache内部についての知識は非常に限られています）。
CGI環境でのPHPを使用している場合は、RFC 3875での仕様は、この変数の存在を保証するようだ：
4.1.8. REMOTE_ADDR
The REMOTE_ADDR variable MUST be set to the network address of the
client sending the request to the server.
CLI SAPIがウェブサーバによって処理されないということを考えれば、私の理論でもあります。値が入力されない可能性があります。しかし、私はApache/Nginxやネットワークが常にIPの値を渡していることを確認したいのですが、リクエストをドロップするだけです。 – Xeoncross
@ Xeonこの質問はPHPについてではなく、Apacheに関するものです。そして、あなたがCGIかapacheモジュールを使っているかどうかに違いがあると思います。 – Artefacto
実際には、私はApacheを使用しません - 私はNginxを使用します。また、質問に記載されているように、私はネットワークインターフェース、Webサーバー、または空のREMOTE_ADDRでPHPが呼び出されないようにするために要求をブロックしている何かを開いています。 – Xeoncross
まあ、それは予約が、書き込み可能です。私は超大域的にいたずら書きしていたひどく書かれたアプリを見てきました。スクリプトがそれを上書きしてしまう可能性があります。 $_SERVER['REMOTE_ADDR'] = '';？
それ以外の場合は、リクエストがプロキシされていても、プロキシのアドレスがある必要があります。何らかの内部書き換えモジュールが混乱している可能性があります（mod_rewriteは内部リダイレクトを許可します。 ？
それは空白にすべきではない、と何がWebサービスに接続することはできません。接続するものには、データを送受信するためのIPアドレスが必要です。そのIPアドレスが信頼できるかどうかは、別の問題です。
はい。私は現在、Apache-behind-Nginxのログで、ログ内の通常の要求/応答のように見えるため、「不明」という値を参照しています。私はこれが可能だと信じているのは、は、X-Forwarded-Forヘッダーのデータに基づいてREMOTE_ADDRをリセットする要求を変更しているためです。したがって、元のREMOTE_ADDRの値が有効である可能性がありますが、逆プロキシとApacheを通過する際に、REMOTE_ADDRはアプリケーションに到着するまでに無効と表示されます。
あなたはPerlのlibwww-perlをインストールしている場合は、あなたが（独自のドメインまたはアプリケーションであることをexample.comを変更する）このように、この状況をテストすることができます。
HEAD -H 'X-Forwarded-For: ' -sSe http://www.example.com/
HEAD -H 'X-Forwarded-For: HIMOM' -sSe http://www.example.com/
HEAD -H 'X-Forwarded-For: <iframe src=http://example.com>' -sSe http://www.example.com/
（また、あなたは可能にする任意の他のツールを使用することができます）カスタムリクエストヘッダーを使用してHTTPリクエストを手作業で作成することができます。
アクセスログを調べてログに記録されている値を確認し、アプリケーションが不正な入力をどのように処理したかを確認します。 `
これは恐ろしいことです：カノニカル情報（ 'REMOTE_ADDR'）をユーザ提供の（' X-FORWARDED-FOR'）に置き換えてください。あなたの分析は正しく聞こえるが、「不明」は[有効な識別子]（https://tools.ietf.org/html/rfc7239#section-6.2）であり、おそらくnginxはそれを[古いプロキシヘッダースキャンロジック]（http://serverfault.com/a/414166/204816）を参照してください。 – bishop
あなたはデータをどこに送り返すべきかについて嘘をつくことはできません... TCPはあなたにパケットを送るためにあなたのIPを知る必要があるので、HTTPリクエストを送る前にTCP接続はSYN/ACKをIPに送信して、接続を作成することができます。 – tobyodavies
データをどこに送り返すかは、確かに嘘です。それはDoS攻撃のいくつかの形式の問題です。 – Xeoncross
@Xeoncross：ソースのなりすましを使ったDoS攻撃は、Apacheまでは行かないでしょう - ネットワーキングスタックは接続を半開状態にしているでしょう（ 'SYN/ACK'を' SYN/ACK'を確実に生成する方法がないため、 ACK '） - これは多くのDoSスプーフィング攻撃のポイントでもあります。ハーフオープン接続用のテーブルは、一部のシステムではごく小規模*でしたが、一度満たされると受け入れを停止しました。とにかく、偽装された送信元アドレスでTCP接続を何とか開いたとしても、空のアドレスではなく* REMOTE_ADDRと表示されます。 – Piskvor