이 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;

여기서 문제는 여기의 두 번째 매개 변수가 지시문 $uri/의 각 파일 index을 차례로 시도하게한다는 것입니다. 아무것도 발견되지 않으면로 이동 /index.html하여 동일한 location블록이 다시 입력되고 여전히 존재하지 않기 때문에 무한 루프가 발생합니다.

이것을 다음과 같이 다시 작성합니다.

        try_files $uri $uri/ =404;

index지시문에 지정한 인덱스 파일이 없으면 404 오류를 반환 합니다.

BTW, 당신이보고있는 요청은 인터넷 배경 소음 입니다. 특히 웹 서버가 개방형 프록시인지 여부를 확인하는 프로브이며 악의적 인 활동을 수행 할 때 악의적 인 사용자의 출처를 숨기도록 악용 될 수 있습니다. 이 구성에서 서버는 공개 프록시가 아니므로 걱정할 필요가 없습니다.

당신 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 {
   ...
}

귀하는 대부분을 /some/thing통해 같은 SEO URL 을 제공합니다 index.php.

그러나 평소 location ~\.php와 같이 직접 노출해야하는 일부 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옵니다.