2017-04-24 13 views
1

nginxのlimit_conn指令を正しく動作させることができません。Nginx指令limit_connが機能しない

私は、次のnginxのconfiguratonがあります

http { 
    limit_conn_zone $binary_remote_addr zone=per_ip:10m; 
    proxy_cache_path /var/nginx/cache/ levels=1:2 keys_zone=caching:10m max_size=10g inactive=525600m use_temp_path=off; 
    server { 
     listen 80; 
     expires -1; 
     limit_conn per_ip 1; 
     limit_conn_status 403; 
     location ~/{ 
      proxy_pass http://upstream; 
      proxy_cache caching; 
     } 
    } 
} 

私は次のPythonスクリプトでサーバーを照会した場合、私は2番目のリクエストが403応答を返す必要があることを期待しています。

import httplib 

headers = {'Connection': 'keep-alive'} 

conn1 = httplib.HTTPConnection('nginx-server') 
conn1.request('GET', '/path/to/resource', '', headers) 
res1 = conn1.getresponse() 
print(res1.status) 

conn2 = httplib.HTTPConnection('nginx-server') 
conn2.request('GET', '/path/to/resource', '', headers) 
res2 = conn2.getresponse() 
# Should print 403 but most often it prints 200 
print(res2.status) 

conn1.close() 
conn2.close() 

2番目の要求に対して応答ステータスコードが一貫していません。場合によっては200が返され、403が返されることもあります。

はおそらく、私は今、私は2番目の要求は常に403

nginxのバージョンを返すことを期待し、limit_connディレクティブの意味を誤解:nginxの/ 1.11.9

答えて

0

私はあなたのセットアップが機能していると思います。私はあなたが時々200を得て、時には403を取得すると思う理由は、時には、2番目のリクエストが実行されるまでに、最初のものがすでに終了しているので、nginxサーバーは接続を再開しません。

私が考え出すことの1つは、リクエストを睡眠で長いリクエストにすることです。 nginxの場合は、echo_sleepを使用して特定の秒間スリープ状態にすることができます。

location ~/{ 
    echo_sleep 1.234; 
    proxy_pass http://upstream; 
    proxy_cache caching; 
} 

あなたの問題を解決したいと考えています。

+0

2番目の接続が要求を発行しているときに最初の接続は閉じられません。これは、私は確信しています(wiresharkでチェック)。実際の作業を行うときにのみ接続がカウントされることがありますが、どこにも記載されていないことがあります。しかし、この指令の目的は何ですか? DDoS攻撃は、サーバーを無駄な接続で埋めることができます。 – olif

関連する問題