What does this nginx error "rewrite or internal redirection cycle" mean?

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"

I am getting these from nginx error log, I don't have a "kowol" sub domain, I don't have any links to qq.com or joesfitness.net on my site. Whats going on?

Edit: Nginx default config:

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;
    #}
}

It's a strange one all right, though I'm going to bet the problem is with:

        try_files $uri $uri/ /index.html;

The problem here is that the second parameter here, $uri/, causes each of the files in your index directive to be tried in turn. If none are found, it then moves on to /index.html, which causes the same location block to be re-entered, and since it still doesn't exist, you get an endless loop.

I would rewrite this as:

        try_files $uri $uri/ =404;

to return a 404 error if none of the index files you specified in the index directive exist.

BTW, those requests you are seeing are Internet background noise. In particular, they are probes to determine whether your web server is an open proxy and can be abused to hide a malicious user's origin when he goes to perform malicious activity. Your server isn't an open proxy in this configuration, so you don't really need to worry about it.

You will also get this error message if your index.php is entirely missing.

This was annoying. It was working a few weeks ago, and it failed on me when I tried today.

I believed an upgrade of Ubuntu nginx package cause the default directory of where Ubuntu kept the standard index files changed, so the line:

root /usr/share/nginx/www;

Won't work anymore as the location of the files are at /usr/share/nginx/html.

To fix, one can just change the root pointer to the correct directory, or create a symlink to the new directory:

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

Works for me.

I ran into this problem yesterday because I was testing nginx over a proxy server that had cached a redirect that no longer existed. The solution for me was to $ sudo service squid3 restart on the squid3 proxy server I was connecting through.