Ruby on rails Nginx 404（未找到）仅适用于AWS上的rails映像

我在生产模式下测试我的应用程序，遇到了一个奇怪的问题。图像资产未加载到网页上。所有css和javascript都可以正常加载，但任何图像都会从nginx获得

404（未找到）

。我正在将我的应用程序与docker一起推送到AWS服务。当我预编译资源时，图像将包含在输出中，因此它们应该在那里：

I, [2017-08-30T12:10:50.092655 #7]  INFO -- : Writing /livingrecipe/public/assets/default-user-d39e051d757a0f45602b6065147cec0a307c6a2a070834f6fe6fc2b0fc914207.jpg
I, [2017-08-30T12:10:50.104846 #7]  INFO -- : Writing /livingrecipe/public/assets/default_recipe-be8d509a8e34dfec514c097b119753d4aaadbfd1dd6747e3c868ed454b8a36b3.jpg
I, [2017-08-30T12:10:50.108486 #7]  INFO -- : Writing /livingrecipe/public/assets/edit-4e381318428d71d55ed0cbdc32b4ce99db6622140c6e7c751ae0f1bfb40d3963.png
I, [2017-08-30T12:10:50.111606 #7]  INFO -- : Writing /livingrecipe/public/assets/favorite-91432751e505915d80cf4e24d7a8d0abd3493d05d2d447c1cebb055d99757ac8.png
I, [2017-08-30T12:10:50.115720 #7]  INFO -- : Writing /livingrecipe/public/assets/icon_email-203dcd7bdcf7559d742f76a9d8c21e98694d45b9556b29ab9ce286a7dd37af11.png
I, [2017-08-30T12:10:50.118457 #7]  INFO -- : Writing /livingrecipe/public/assets/icon_facebook-0140437ec6cb29bc6ac6f8505f05f11603a430298e48c1ea483f7de390ba34a9.png
I, [2017-08-30T12:10:50.121393 #7]  INFO -- : Writing /livingrecipe/public/assets/icon_google-2a98026430dddc53539d283c04a2ad4b50536c93d0becadb03f3f61443e52c9c.png
I, [2017-08-30T12:10:50.125228 #7]  INFO -- : Writing /livingrecipe/public/assets/star-half-db15fb9b3561d5c741d8aea9ef4f0957bd9bc51aa1caa6d7a5c316e083c1abd5.png
I, [2017-08-30T12:10:50.127714 #7]  INFO -- : Writing /livingrecipe/public/assets/star-off-6aaeebdaab93d594c005d366ce0d94fba02e7a07fd03557dbee8482f04a91c22.png
I, [2017-08-30T12:10:50.130083 #7]  INFO -- : Writing /livingrecipe/public/assets/star-on-fd26bf0ea0990cfd808f7540f958eed324b86fc609bf56ec2b3a5612cdfde5f5.png
I, [2017-08-30T12:10:50.132442 #7]  INFO -- : Writing /livingrecipe/public/assets/unfavorite-7000a53c81f55cf94c88031a8529f847e5a6abd7460e0e54ae0b581b0cde85a3.png

这是我的nginx的default.conf文件：

upstream PLACEHOLDER_BACKEND_NAME {
  # The web app.
  server PLACEHOLDER_BACKEND_NAME:PLACEHOLDER_BACKEND_PORT;
}

# Redirect 'www' addresses to the non-www version, and also take care of
# redirects to HTTPS at the same time.
server {
  listen 80;
  server_name www.PLACEHOLDER_VHOST;
  return 301 https://$host$request_uri;
}

server {
  # "deferred" reduces the number of formalities between the server and client.
  listen 80 default deferred;
  server_name PLACEHOLDER_VHOST;

  # Static asset path, which is read from the PLACEHOLDER_BACKEND_NAME
  # container's VOLUME.
  root /PLACEHOLDER_BACKEND_NAME/public;

  # Serve static assets.
  #
  # gzip_static is enabled because the assets are already gzipped to a maximum
  # level due to Rail's asset pipeline.
  #
  # Add headers to set the maximum amount of cache time.
  #
  # We can do this because the Ruby on Rails asset pipeline md5 hashes all of
  # the file names for us. When a file changes, its md5 will change, and the
  # cache will be automatically busted. Other frameworks can do this as well.
  location ~ ^/assets/ {
    gzip_static on;

    # Set a maximum cache time period and null out a few headers to address
    # certain browsers from occasionally requesting cached content.
    expires max;
    add_header Cache-Control public;
    add_header Last-Modified "";
    add_header ETag "";
  }

  # Ensure timeouts are equal across browsers.
  keepalive_timeout 60;

  # Disallow access to hidden files and directories.
  location ~ /\. {
    return 404;
    access_log off;
    log_not_found off;
  }

  # Allow optionally writing an index.html file to take precedence over the upstream.
  try_files $uri $uri/index.html $uri.html @PLACEHOLDER_BACKEND_NAME;

  # Attempt to load the favicon or fall back to status code 204.
  location = /favicon.ico {
    try_files /favicon.ico = 204;
    access_log off;
    log_not_found off;
  }

  # Force SSL connections on agents (browsers) who support this header.
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;";

  # Load the web app back end with proper headers.
  location @PLACEHOLDER_BACKEND_NAME {
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_redirect off;

    if ($http_x_forwarded_proto = "http") {
      return 301 https://$host$request_uri;
    }

    proxy_pass http://PLACEHOLDER_BACKEND_NAME;
  }
}

---

我将根据经验来回答，尽管我对Nginx+Django也有同样的问题。保存我的情况的是给运行服务器的用户（可能是

www-data

，在我的情况下是我）访问图像的权限。是的，这听起来很愚蠢，因为它对其他文件有权限，但这很有帮助。试一试

sudo chmod -R 750 /root/of/website

这将递归地授予该目录中所有文件的权限。希望有帮助

---

注意：这可能不是问题所在，因此如果没有帮助，请不要否决。

因此，引用资产的方法是错误的，这是一个简单的错误。在rails中，我使用的是：

<%= asset_path('/assets/image.png') %>

它在开发模式下仍然显示资产，但在生产模式下找不到，因为它已经添加了资产文件夹，所以正在查看资产/资产/图像。将所有内容更改为：

<%= asset_path('image.png') %>

---

它应该是这样的，并且运行得很好。

那么将其添加到nginx conf文件中？不，在shell中运行它（我假设您使用linux是出于某种原因。如果不是这样，请说）。如果这不起作用，那么在您的问题中发布确切的nginx日志