Apache 特定HTTP重定向帮助-“；请求超出了10个内部重定向的限制”；

关于这个问题有很多线索。但没有人有我的具体问题

我们的设置简介：我们在端口80上运行Nginx，它位于端口8889上Apache的前面

我们在Nginx或Apache中没有做任何更改，这个设置已经运行了一段时间。这就是为什么我们要为今天早上突然发生的事情挠头。我们的网站现在有500个错误

从日志来看，我认为它们不是由Nginx引起的，而是由Apache引起的：

[Fri Aug 01 23:08:33 2014][error][client 100.99.98.97]由于可能的配置错误，请求超出了10个内部重定向的限制。如有必要，使用“LimitInternalRecursion”增加限制。使用“LogLevel debug”获取回溯跟踪。参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3112）：[client 100.99.98.97]r->uri=/beta/actionize，参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/
[Fri Aug 01 23:08:33 2014][debug]core.c（3118）：[client 100.99.98.97]已从r->uri=/beta/actionize重定向，请参考：http://somedomain.com/acordes/2011/01/entre-palos-y-alegrias/

在该域的

.htaccess

文件中，我们有以下代码：

Options -Indexes +FollowSymLinks -MultiViews
DirectoryIndex index index.php index.htm index.html
DefaultType application/x-httpd-php

RewriteEngine On

# If someone types just the folder name
RewriteRule ^beta$ http://%{HTTP_HOST}/beta/index [L,R=301]

# If someone types the correct file, just show it
RewriteRule ^beta/(.*)$ /beta/$1 [L]

# All other URLs..
RewriteCond %{REQUEST_URI} !^(mailman|pipermail|w3c)/
RewriteRule ^(.*)$ /beta/get?u=$1 [L,QSA]

逻辑很简单。对于根目录中的所有.htm等文件，我们只显示它们。对于任何以

/beta/[xyz]

开头的URL，我们还将显示根文件夹中硬“beta”文件夹中的文件

但是对于以我们的域开始的所有其他URL，我们希望将代码转发到

/beta/get？

，参数是URI的一部分

例如，如果有人键入：

http://EXAMPLE.com/xyz123

，我们希望在内部重定向到：

http://EXAMPLE.com/beta/get?u=xyz123

（除了用于我们的特定邮件列表的单词mailman或pipermail等）

仅供参考，NGINX.CONF文件如下：

#-------------------- START ------------------#
http {

  server_name_in_redirect       off;
  server_names_hash_max_size    10240;
  server_names_hash_bucket_size 1024;

  gzip on;
  gzip_static           on;
  gzip_disable          "MSIE [1-6]\.";
  gzip_vary             on;
  gzip_proxied          any;
  gzip_comp_level       5;  # Not a huge compression beyond this..so save CPU cycles
  gzip_buffers          16 8k;
  gzip_http_version     1.1;
  gzip_types            text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript image/png image/gif image/jpeg;

  connection_pool_size        256;
  client_header_buffer_size   256k;
  large_client_header_buffers 4 256k;
  client_max_body_size        200M; 

  client_body_buffer_size       128k;
  request_pool_size             64k;
  output_buffers                16 256k;

  open_file_cache               max=5000 inactive=20s; 
  open_file_cache_valid         60s; 

  include                       mime.types;
  default_type                  application/octet-stream;

  error_log                     logs/error.log warn;
  access_log                    off;
  server_tokens                 off; 
  autoindex                     off; 
  sendfile                      off;
  ignore_invalid_headers        on;    # Malware protection
  reset_timedout_connection     on;    # DDoS protection

  # Timeouts
  client_header_timeout         5;
  client_body_timeout           50;
  send_timeout                  50;
  keepalive_timeout             65;   # No need for default 65, but having some keepalive speeds things up
  resolver_timeout              1s;

  proxy_cache_path /dev/shm/proxy_cache levels=1:2 keys_zone=proxyone:200m inactive=1h max_size=2g;
  proxy_cache_key "$scheme$host$request_uri$cookie___snippa$cookie___sniplang";

  proxy_cache             proxyone;
  proxy_cache_min_uses    5;         
  proxy_cache_valid       any 60s;   
  proxy_cache_valid       200 1m; 
  proxy_cache_valid       404 0s;    
  proxy_cache_valid       410 90d;   
  proxy_cache_valid       500 502 503 504 1s;

  proxy_cache_valid       301 60m;
  proxy_ignore_headers    X-Accel-Expires Expires Cache-Control;


set_real_ip_from   192.168.1.0/24;
set_real_ip_from   192.168.2.1;
set_real_ip_from   127.0.0.1;
real_ip_header     X-Real-IP;


  server
  {
    listen 127.0.0.1:80;
    listen 74.86.191.114:80;
    listen 100.99.98.97:80;
    listen 75.126.161.225:80;
    listen 75.126.161.226:80;
    listen 10.17.32.66:80;

    server_name     EXAMPLE.com   www.EXAMPLE.com;

    root /home/EXAMPLE/public_html;
    index index.htm index.php index index.htm;

    error_page 403 = @backend;
    error_page 404 = @backend;
    error_page 405 = @backend;
    error_page 406 = @backend;
    error_page 500 = @backend;
    error_page 501 = @backend;
    error_page 502 = @backend;
    error_page 503 = @backend;
    error_page 504 = @backend;
    error_page 505 = @backend;


    # IMPORTANT FILES 
    location = /\.htaccess        { deny all; access_log off; log_not_found off; }
    location ~ /\.ht              { deny all; access_log off; log_not_found off; }
    location = /favicon.ico       { log_not_found off; access_log off; expires  max; }
    location = /robots.txt        { allow all; log_not_found off; access_log off; expires  max; }
    location = /sitemap.gz        { allow all; log_not_found off; access_log off; expires  max; }
    location = /crossdomain.xml   { allow all; log_not_found off; access_log off; expires  max; }


    location / {

      location ~.*\.(gif|jpg|png|ico|swf|rss|xml|htm|txt|js|css|gz|doc|xls|pdf|html|woff|eot|svg)$   {
        expires         max;
        try_files       $uri    @backend;
        log_not_found   off; 
      }

      proxy_pass http://100.99.98.97:8889;
      include proxy.inc;
    }

    location @backend {
      internal;
      proxy_pass http://100.99.98.97:8889;
      include proxy.inc;
    }

  }  # End of EXAMPLE.COM server block 


} # End of http block 

---

这可能是什么原因造成的？apache中的

logleveldebug

似乎没有多大帮助。非常感谢任何建议或指点

您认为规则正在导致循环。重写引擎一次又一次地重新应用所有规则，直到URI停止更改。尝试添加更多的恢复循环：

Options -Indexes +FollowSymLinks -MultiViews
DirectoryIndex index index.php index.htm index.html
DefaultType application/x-httpd-php

RewriteEngine On

# If someone types just the folder name
RewriteRule ^beta/?$ http://%{HTTP_HOST}/beta/index [L,R=301]

# If someone types the correct file, just show it
RewriteRule ^beta/(.+)$ /beta/$1 [L]

# All other URLs..
RewriteCond %{REQUEST_URI} !^(mailman|pipermail|w3c|beta)/
RewriteRule ^(.*)$ /beta/get?u=$1 [L,QSA]

---

也就是说，在

/beta

的末尾有一个可选的

/

，一个

+

而不是

*

，以确保

/

后面至少有一个字符，并将

beta

添加到最后一条规则的条件中。

谢谢。我现在将它们移动到

httpd.conf

，而不是.htaccess。在所有重写规则前面添加“/”可以吗？是的，在非目录中，添加的规则需要在前面添加“/”