【问题标题】:Why does Nginx keep returning 301?为什么 Nginx 总是返回 301?
【发布时间】:2014-03-30 21:16:58
【问题描述】:

我有一个配置为与上游独角兽对话的 nginx 设置(它是一个 rails 应用程序)。我已经检查了基础知识。我知道请求正在到达 nginx,它映射到 server_name,它找到 try_files 指令,它落到最后一个指令,即 @unicorn 映射到位置块。在 location 块中,我有这个:

location @unicorn {
        # an HTTP header important enough to have its own Wikipedia entry:
        #   http://en.wikipedia.org/wiki/X-Forwarded-For
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # this helps Rack set the proper URL scheme for doing HTTPS redirects:
        proxy_set_header X-Forwarded-Proto $scheme;

        # pass the Host: header from the client right along so redirects
        # can be set properly within the Rack application
        proxy_set_header Host $http_host;

        # we don't want nginx trying to do something clever with
        # redirects, we set the Host: header above already.
        proxy_redirect off;

        proxy_pass http://unicorn_myapp;
      }

然后再往上我的文件

upstream unicorn_myapp {
  # fail_timeout=0 means we always retry an upstream even if it failed
  # to return a good HTTP response (in case the Unicorn master nukes a
  # single worker for timing out).
  server unix:/etc/sockets/unicorn.myapp.sock;
}

我也有独角兽在同一个套接字上监听。这是我的 unicorn conf 文件中的一个 sn-p:

# Use at least one worker per core if you're on a dedicated server,
# more will usually help for _short_ waits on databases/caches.
worker_processes 2

# Help ensure your application will always spawn in the symlinked
# "current" directory that Capistrano sets up.
working_directory "/home/deployer/apps/myapp/current"

# listen on both a Unix domain socket
# we use a shorter backlog for quicker failover when busy
listen "/etc/sockets/unicorn.myapp.sock", :backlog => 64

我已经验证了两个守护进程都在运行,套接字文件存在(例如,独角兽正在监听)并且没有权限问题,因为这会被记录。说到日志,每当我请求根目录时,nginx 都会返回:

HTTP/1.1 301 Moved Permanently
Server: nginx/1.4.6
Date: Sun, 30 Mar 2014 21:05:55 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Status: 301 Moved Permanently
Location: https://myapp.com

这会记录在 nginx 的访问日志中:

xx.xx.xx.xx - - [30/Mar/2014:17:05:55 -0400] "GET / HTTP/1.1" 301 5 "-" "-"

Unicorn 的日志中什么都没有。这里会发生什么?

【问题讨论】:

  • 你的应用根目录下应该有一个文件config/unicorn.rb,里面有一行'listen APP_PATH + "/tmp/pids/.unicorn.sock", :backlog => 64',它描述了 Unicorn 套接字的位置,供您的 nginx 服务器监听。这是否与您的 nginx 配置匹配?
  • 确实匹配。如果你仔细看的话,我实际上在我原来的帖子中发布了那个文件。
  • 除非用户“deployer”在 /etc/sockets 目录中有写权限(我严重怀疑),这是绝对正常的。您可以通过进入 /etc/sockets 并执行以下操作之一来检查这一点: 如果您说 unicorn.log 为空,只需执行“touch unicorn.log”...您可能会看到一个错误。如果不是,那么“mv unicorn.log unicorn.log.bak && touch unicorn.log”。您可能会看到一个错误。我建议您将套接字的位置更改为 rails 文件夹中的临时文件夹,正如我在之前的评论中向您展示的那样。如果不是,至少使该文件可写入“部署者”
  • Deployer 确实具有对该目录的写入权限,因为我专门为此目的创建了该目录并授予该用户写入权限:root@myapp-dev:/etc# ls -lad soc* drwxrwxr-x 2 deployer web 4096 Mar 30 16:45 sockets srwxrwxrwx 1 deployer deployer 0 Mar 30 16:45 unicorn.myapp.sock

标签: ruby-on-rails linux ubuntu unicode nginx


【解决方案1】:

我明白了。实际上,我的 production.rb 文件中有 force_ssl = true

【讨论】:

    猜你喜欢
    • 2020-06-07
    • 2021-01-24
    • 1970-01-01
    • 2014-09-12
    • 2016-09-16
    • 1970-01-01
    • 2013-03-14
    • 2019-09-18
    • 2012-06-25
    相关资源
    最近更新 更多