【问题标题】:Nginx is ignoring client_max_body_sizeNginx 忽略了 client_max_body_size
【发布时间】:2012-02-21 12:41:23
【问题描述】:

由于某种原因,将client_max_body_size 16M; 放在我的 nginx.conf 文件中没有任何效果 - 当我尝试将图像上传到我的网络服务器时,我仍然收到 HTTP 413 错误。每次更改配置文件后,我都重新启动了 Nginx,并尝试将 client_max_body_size 指令放在 location {} 块、服务器 {} 块和 http {} 块中。我什至同时尝试了所有三个。

在四处寻找这个问题的答案时,有人建议在其他配置文件中寻找 client_max_body_size 行,比如我没有的 proxy.conf。

我的 Nginx 配置没有什么特别之处 - 只是将连接上传到在端口 8080 上运行的一组 Rainbows(独角兽)。

我正在尝试上传一个 4.5mb 的 jpg 文件,在 Ubuntu 11.10 上运行 Nginx 1.0.5。知道为什么这不起作用吗?

更新:

似乎有一个 (?) Rainbows 工作人员每 30 秒重新启动一次。这是 rainbows.stderr.log 的输出:

E, [2012-01-29T17:27:05.977487 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)  
E, [2012-01-29T17:27:05.978011 #25218] ERROR -- : retrying in 0.5 seconds (4 tries left)  
E, [2012-01-29T17:27:06.478767 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)  
E, [2012-01-29T17:27:06.478964 #25218] ERROR -- : retrying in 0.5 seconds (3 tries left)  
E, [2012-01-29T17:27:06.979509 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)  
E, [2012-01-29T17:27:06.979650 #25218] ERROR -- : retrying in 0.5 seconds (2 tries left)
E, [2012-01-29T17:27:07.480190 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)
E, [2012-01-29T17:27:07.480353 #25218] ERROR -- : retrying in 0.5 seconds (1 tries left)  
E, [2012-01-29T17:27:07.980809 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)  
E, [2012-01-29T17:27:07.980987 #25218] ERROR -- : retrying in 0.5 seconds (0 tries left)  
E, [2012-01-29T17:27:08.481638 #25218] ERROR -- : adding listener failed addr=0.0.0.0:8080 (in use)  
/usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/socket_helper.rb:144:in `initialize': Address already in use - bind(2) (Errno::EADDRINUSE)  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/socket_helper.rb:144:in `new'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/socket_helper.rb:144:in `bind_listen'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:222:in `listen'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:733:in `block in inherit_listeners!'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:733:in `each'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:733:in `inherit_listeners!'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/unicorn-4.1.1/lib/unicorn/http_server.rb:121:in `start'
from /usr/local/forrager/shared/bundle/ruby/1.9.1/gems/rainbows-4.3.1/bin/rainbows:122:in `<top (required)>'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/bin/rainbows:19:in `load'  
from /usr/local/forrager/shared/bundle/ruby/1.9.1/bin/rainbows:19:in `<main>'  

【问题讨论】:

    标签: ruby-on-rails upload nginx unicorn


    【解决方案1】:

    我终于在同事的帮助下解决了这个问题。原来问题的发生是因为我没有正确配置 Rainbows (Unicorn)。除了在 Nginx 配置中指定最大主体大小之外,我还应该在我的 Rainbows 配置中指定它。我之前曾尝试在我的 Rainbows 配置中调用 client_max_body_size,但没有成功。事实证明,client_max_body_size 调用应该放在 Rainbows 中!像这样阻止:

    Rainbows! do
      client_max_body_size(16 * 1024 * 1024) # 16 megs
    end
    

    问题解决了。我现在可以毫无问题地上传 4 和 5 mb 的文件。谢谢大家!

    【讨论】:

      【解决方案2】:

      你说的那一点没什么特别的,实际上是。确保 Unicorn 进程可以写入 /tmp 中的文件 - 超过一定大小的任何内容都会写入磁盘而不是保存在内存中。所以确保它可以制作临时文件。详见 Unicorn 中的 tmpio.rb。

      另外,请确保您在 http {} 下有 client_max_body_size 并且没有其他地方。

      【讨论】:

      • 感谢您的回复! /tmp 的权限是 777 全局可写的,我将 Nginx 配置更改为在 http {} 下只有 client_max_body_size。不幸的是,它仍然无法正常工作。在上传期间观看 /tmp 的ls 并没有显示在那里创建任何新内容。我还能如何检查以确保 Unicorn 可以访问 /tmp?
      • 检查您是否可以自己发布到独角兽。暂时将 nginx 排除在外。 Unicorn 将自己呈现为 HTTP,因此可以直接访问它。
      • 嗯!好建议。我看到了其他非常奇怪的问题。在 Chrome 开发人员工具(直接连接到 Unicorns)中查看请求/响应时,请求立即失败,但实际上并没有给我错误代码。 /add_image 请求变为红色,但好像失败了。还有其他几个 about:blank 条目显示,只有标题信息,另一个看起来像 base-64 编码的 PNG 文件(我正在上传 jpg)。很奇怪。我还缺少其他独角兽设置吗?发送文件或类似的东西?
      • 听起来后面(独角兽)比 nginx 更重要。
      • 确实如此。将继续调查。
      猜你喜欢
      • 1970-01-01
      • 2022-01-23
      • 2019-07-27
      • 2018-02-20
      • 2015-04-13
      • 1970-01-01
      • 1970-01-01
      • 2017-01-02
      • 2011-06-24
      相关资源
      最近更新 更多