NGINX第二個limit_req重寫後不工作

這個limit_req配置的工作原理是，如果我直接打開php頁面（index.php），但不是如果打到/ [漂亮的URL]並將其重寫爲index.php？$ args。NGINX第二個limit_req重寫後不工作

limit_req_zone $binary_remote_addr zone=dynamic:10M rate=1r/s; 
limit_req_zone $binary_remote_addr zone=static:10M rate=60r/s; 

location/{ 
      limit_req zone=static burst=180; 
      try_files $uri $uri/ /index.php?$args; 
    } 

location ~ \.php$ { 
      limit_req zone=dynamic burst=5; 
      fastcgi_split_path_info ^(.+\.php)(/.+)$; 

      set $fsn /index.php; 
      if (-f $document_root$fastcgi_script_name){ 
        set $fsn $fastcgi_script_name; 
      } 

      fastcgi_pass unix:/var/run/php5-fpm.sock; 
      include fastcgi_params; 
      fastcgi_param SCRIPT_FILENAME $document_root$fsn; 
      fastcgi_param PATH_INFO  $fastcgi_path_info; 
      fastcgi_param PATH_TRANSLATED $document_root$fsn; 
    }

很明顯，它傳遞到了正確的位置，因爲它傳遞到了後端，但limit_req似乎沒有被使用。我無法在文檔中找到討論此限制的任何內容。有沒有人有任何想法？

編輯：註釋掉zone = static的第一個允許php處理一個工作。對我來說，這看起來像是limit_req中的一個bug。

來源

2014-11-22 RobC

什麼是limit_req_zone內容？ – 2014-11-22 08:49:43

limit_req_zones在代碼塊的最頂部定義 – RobC 2014-12-03 07:11:57

看起來這只是NGINX和limit_req模塊的工作方式......也許將來它會變得更好。

經過大量的挖掘，我發現一個nginx論壇帖子，談論這個http://forum.nginx.org/read.php?2,223426,223431，它似乎是一個或兩個以下是真實的（我沒有興趣深入挖掘這個任何進一步）。

看起來好像limit_req是否在使用try_files指令的'location'中使用，未來將使用limit_req指令。
它可能是一旦某個位置處理了limit_req指令，它們將不會在另一個「位置」處理，但是單個「位置」中的多個limit_reqs應該可以正常工作。

到目前爲止，我的配置的解決方案是從/刪除limit_req併爲靜態文件設置新的位置正則表達式匹配，並將靜態數據的limit_req放入那裏。

來源

2014-12-03 07:06:54 RobC

NGINX第二個limit_req重寫後不工作

回答

相關問題