このnginxエラー「書き換えまたは内部リダイレクトサイクル」とはどういう意味ですか？

tail -f /var/log/nginx/error.log
2013/05/04 23:43:35 [error] 733#0: *3662 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET /robots.txt HTTP/1.1", host: "kowol.mysite.net"
HTTP/1.1", host: "www.joesfitness.net"
2013/05/05 00:49:14 [error] 733#0: *3783 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET / http://www.qq.com/ HTTP/1.1", host: "www.qq.com"
2013/05/05 03:12:33 [error] 733#0: *4232 rewrite or internal redirection cycle while internally redirecting to "/index.html", client: 127.0.0.1, server: _, request: "GET / HTTP/1.1", host: "joesfitness.net"

私はnginxエラーログからこれらを取得しています、「kowol」サブドメインがありません、私のサイトにqq.comまたはjoesfitness.netへのリンクがありません。どうしたの？

編集：Nginxのデフォルト設定：

server {
    listen   8080; ## listen for ipv4; this line is default and implied
    listen   [::]:8080 default ipv6only=on; ## listen for ipv6

    root /usr/share/nginx/www;
    index index.php index.html index.htm;

    # Make site accessible from http://localhost/
    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to index.html
        try_files $uri $uri/ /index.html;
        # Uncomment to enable naxsi on this location
        # include /etc/nginx/naxsi.rules
    }

    location /doc/ {
        alias /usr/share/doc/;
        autoindex on;
        allow 127.0.0.1;
        deny all;
    }

    # Only for nginx-naxsi : process denied requests
    #location /RequestDenied {
        # For example, return an error code
        #return 418;
    #}

    #error_page 404 /404.html;

    # redirect server error pages to the static page /50x.html
    #
    #error_page 500 502 503 504 /50x.html;
    #location = /50x.html {
    #   root /usr/share/nginx/www;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

        # With php5-cgi alone:
        fastcgi_pass 127.0.0.1:9000;
        #With php5-fpm:
        #fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #   deny all;
    #}
}

それは奇妙なものですが、問題は次のとおりです。

        try_files $uri $uri/ /index.html;

ここでの問題は、ここの2番目のパラメーターで、ディレクティブ$uri/内の各ファイルindexが順番に試行されることです。何も見つからない場合は、に進み/index.html、同じlocationブロックが再入力されます。まだ存在しないため、無限ループになります。

これを次のように書き換えます。

        try_files $uri $uri/ =404;

indexディレクティブで指定したインデックスファイルが存在しない場合、404エラーを返します。

ところで、あなたが見ているそれらの要求は、インターネットのバックグラウンドノイズです。特に、Webサーバーがオープンプロキシであり、悪意のあるユーザーが悪意のあるアクティビティを実行しようとするときに、悪意のあるユーザーのオリジンを隠すために悪用される可能性があるかどうかを判断するプローブです。この構成では、サーバーはオープンプロキシではないため、実際に心配する必要はありません。

index.phpが完全に見つからない場合にも、このエラーメッセージが表示されます。

これは迷惑だった。数週間前に機能していましたが、今日試したときに失敗しました。

Ubuntu nginxパッケージをアップグレードすると、Ubuntu が標準のインデックスファイルを保持していた場所のデフォルトディレクトリが変更されるため、次の行を使用します。

root /usr/share/nginx/www;

ファイルの場所がであるため、もう機能しません/usr/share/nginx/html。

修正するには、ルートポインターを正しいディレクトリに変更するか、新しいディレクトリへのシンボリックリンクを作成します。

cd /usr/share/nginx
sudo ln -s html www

私のために働く。

昨日、この問題に出くわしたのは、もはや存在しないリダイレクトをキャッシュしていたプロキシサーバーでnginxをテストしていたからです。私にとっての解決策$ sudo service squid3 restartは、接続していたsquid3プロキシサーバーを使用することでした。

今日このエラーが発生した場合、原因を解明するのに数時間費やします。誰かがサイトのすべてのファイルを削除したことが判明しました。

これが発生したときに別のケースを追加するだけです。受け入れられた答えのように、一般に、試行されるロケーションのシーケンスと、内部リダイレクトループ（終わりのない）の並べ替えが作成されると、これが発生します。

NGINXの設定が正しくない場合や、制限されたchmodでさえ（場合によってはロックダウン設定で）現れます。以下に例を示します。

index.php通常のように、フロントコントローラーがあるとします。

location / {
    try_files $uri $uri/ /index.php?$args;
}
location ~\.php {
   ...
}

ほとんどの場合、SEO URLを提供/some/thingしますindex.php。

しかし、いつものように、直接公開する必要があるPHPファイルがいくつかあります（したがって、location ~\.phpではなくlocation = /index.php。

また、セキュリティロックダウンのために0400 index.phpにchmod設定されているとします。

この場合、ファイルが「PHP-FPMユーザー」によって所有されている限り、すべて正常に機能します。NGINXは、ファイル名をPHP-FPMに渡して実行し、FastCGI応答を返すだけなので、ファイルを読み取る必要はありません。

次に、誰かが訪れ/non-existent.phpたときに何が起こるかというケースを処理したいと思います。というのは、このかなり標準的な構成ではNo input file specified.、そのケースで得られるからです。

これに対処するために、一部の人々は以下を追加します：

if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss

まあ、もちろんifnginxごとに悪ですが、それはそれについてではありません。これで、すべてがリダイレクトサイクルエラーで壊れます。どうして？

このシーケンスはループで発生するため：

• ときに/some/pageURLが要求され、nginxのは入りlocation /、実際のファイルを検索し、それをオンにしません。/index.php
• その後、.phpロケーションブロックに入り、読み取り可能かどうかを確認しようとしますindex.php。それができないので、それを同じものに書き直して、再びindex.php到着.phpします。