很多人都可以碰到一個陷阱。下面我們列出，我們經常看到的問題，以及解釋如何解決這些問題。在Freenode上的#nginx IRC頻道這些討論很頻繁。
從來不要使用777權限，查看目錄的權限
namei -om /path/to/check
BAD：
server { server_name www.example.com; location / { root /var/www/nginx-default/; # [...] } location /foo { root /var/www/nginx-default/; # [...] } location /bar { root /var/www/nginx-default/; # [...] }}GOOD：
server { server_name www.example.com; root /var/www/nginx-default/; location / { # [...] } location /foo { # [...] } location /bar { # [...] }}BAD:
http { index index.php index.htm index.html; server { server_name www.example.com; location / { index index.php index.htm index.html; # [...] } } server { server_name example.com; location / { index index.php index.htm index.html; # [...] } location /foo { index index.php; # [...] } }}GOOD:
http { index index.php index.htm index.html; server { server_name www.example.com; location / { # [...] } } server { server_name example.com; location / { # [...] } location /foo { # [...] } }}if 是邪惡的 參見 If Is Evil
BAD:
server { server_name example.com *.example.com; if ($host ~* ^www/.(.+)) { set $raw_domain $1; rewrite ^/(.*)$ $raw_domain/$1 permanent; } # [...] }}每次都要檢測主機頭，這是低效的，你應該避免，推薦使用下面的
GOOD:
server { server_name www.example.com; return 301 $scheme://example.com$request_uri;}server { server_name example.com; # [...]}這樣方式便于閱讀，降低了nginx的處理要求，而且也避免了硬編碼（http or https）
使用if來判斷是可怕的，你應該使用 try_files
BAD:
server { root /var/www/example.com; location / { if (!-f $request_filename) { break; } }}GOOD:
server { root /var/www/example.com; location / { try_files $uri $uri/ /index.html; }}try_files 意味著你測試一個隊列 $uri => $uri/ => index.html，這種方法簡單，而且可以避免if
Drupal, Joomla, etc. to work, just use this:
try_files $uri $uri/ /index.php?q=$uri&$args;
Note - the parameter names are different based on the package you’re using. For example:
一些軟件不需要 query string, 可以讀取 REQUEST_URI (例如，WordPress):
try_files $uri $uri/ /index.php;
如果你不關心目錄是否存在，你可以移除 $uri/
很多PHP網站中，配置nginx的例子中建議使用 .php （to the PHP interpretet）作為uri的結尾，這例有一個嚴重的安全問題對于大多數PHP程序，因為它可能允許執行任何第三方代碼
The problem section usually looks like this:
location ~* /.php$ { fastcgi_pass backend; # [...]}Here, every request ending in .php will be passed to the FastCGI backend. The issue with this is that the default PHP configuration tries to guess which file you want to execute if the full path does not lead to an actual file on the filesystem.
For instance, if a request is made for /forum/avatar/1232.jpg/file.php which does not exist but if/forum/avatar/1232.jpg does, the PHP interpreter will process /forum/avatar/1232.jpg instead. If this contains embedded PHP code, this code will be executed accordingly.
Options for avoiding this are:
location ~* (file_a|file_b|file_c)/.php$ { fastcgi_pass backend; # [...]}location /uploaddir { location ~ /.php$ {return 403;} # [...]}location ~* /.php$ { try_files $uri =404; fastcgi_pass backend; # [...]}location ~* /.php$ { location ~ /..*/.*/.php$ {return 404;} fastcgi_pass backend; # [...]}盡量使用 include fastcgi_params 中的變量，不管什么語言都是一樣
GOOD:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
BAD:
fastcgi_param SCRIPT_FILENAME /var/www/yoursite.com/$fastcgi_script_name;
我們應該努力讓他們保持整潔。很簡單，不添加冗余代碼。
BAD:
rewrite ^/(.*)$ http://example.com/$1 permanent;
GOOD:
rewrite ^ http://example.com$request_uri? permanent;
BETTER:
return 301 http://example.com$request_uri;
通過使用內置的變量$ REQUEST_URI，我們可以有效地避免做任何捕獲或匹配的。
http://很簡單，除非你告訴NGINX他們不是重寫是相對的。一個重寫絕對很簡單。添加一個scheme
BAD:
rewrite ^ example.com permanent;
GOOD:
rewrite ^ http://example.com permanent;
添加 http:// 到重寫規則內，簡單，高效
BAD:
server { server_name _; root /var/www/site; location / { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/tmp/phpcgi.socket; }}Yucky. In this instance, you pass EVERYTHING to PHP. Why? Apache might do this, you don’t need to. Let me put it this way... The try_files directive exists for an amazing reason. It tries files in a specific order. This means that NGINX can first try to server the static content. If it can’t, then it moves on. This means PHP doesn’t get involved at all. MUCH faster. Especially if you’re serving a 1MB image over PHP a few thousand times versus serving it directly. Let’s take a look at how to do that.
GOOD:
server { server_name _; root /var/www/site; location / { try_files $uri $uri/ @proxy; } location @proxy { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/tmp/phpcgi.socket; }}Also GOOD:
server { server_name _; root /var/www/site; location / { try_files $uri $uri/ /index.php; } location ~ /.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass unix:/tmp/phpcgi.socket; }}It’s easy, right? You see if the requested URI exists and can be served by NGINX. If not, is it a directory that can be served. If not, then you pass it to your proxy. Only when NGINX can’t serve that requested URI directly does your proxy overhead get involved.
Now.. consider how much of your requests are static content, such as images, CSS, javascript, etc. That’s probably a lot of overhead you just saved.
Browser cache. Your configuration may be perfect but you’ll sit there and beat your head against a cement wall for a month. What’s wrong is your browser cache. When you download something, your browser stores it. It also stores how that file was served. If you are playing with a types{} block you’ll encounter this.
The fix:
If this does not work, and you’re running NGINX on a virtual machine in VirtualBox, it may be sendfile() that is causing the trouble. Simply comment out the sendfile directive or set it to “off”. The directive is most likely found in your nginx.conf file.:
sendfile off;
If you do not explicitly set underscores_in_headers on, NGINX will silently drop HTTP headers with underscores (which are perfectly valid according to the HTTP standard). This is done in order to prevent ambiguities when mapping headers to CGI variables as both dashes and underscores are mapped to underscores during that process.
Some directories in any file system should never be used for hosting data from. Some of these include / androot. You should never use these as your document root.
Doing this leaves you open to a request outside of your expected area returning private data.
NEVER DO THIS!!! (yes, we have seen this)
server { root /; location / { try_files /web/$uri $uri @php; } location @php { [...] }}When a request is made for /foo, the request is passed to php because the file isn’t found. This can appear fine, until a request in made for /etc/passwd. Yup, you just gave us a list of all users on that server. In some cases, the NGINX server is even set up run workers as root. Yup, we now have your user list as well as password hashes and how they’ve been hashed. We now own your box.
The Filesystem Hierarchy Standard defines where data should exist. You should definitely read it. The short version is that you want your web content to exist in either /var/www/, /srv, /usr/share/www.
NGINX packages that exist in Ubuntu, Debian, or other Operating systems, as an easy-to-install package will often provide a ‘default’ configuration file as an example of configuration methods, and will often include a document root to hold a basic HTML file.
Most of these packaging systems do not check to see if files are modified or exist within the default document root, which can result in code loss when the packages are upgraded. Experienced system administrators know that there is no expectation of the data inside the default document root to remain untouched during upgrades.
You should not use the default document root for any site-critical files. There is no expectation that the default document root will be left untouched by the system and there is an extremely high possibility that your site-critical data may be lost upon updates and upgrades to the NGINX packages for your operating system.
BAD:
upstream { server http://someserver;}server { listen myhostname:80; # [...]}You should never use a hostname in a listen directive. While this may work, it will come with a large number of issues. One such issue being that the hostname may not resolve at boot time or during a service restart. This can cause NGINX to be unable to bind to the desired TCP socket which will prevent NGINX from starting at all.
A safer practice is to know the IP address that needs to be bound to and use that address instead of the hostname. This prevents NGINX from needing to look up the address and removes dependencies on external and internal resolvers.
This same issue applies to upstream locations. While it may not always be possible to avoid using a hostname in an upstream block, it is bad practice and will require careful considerations to prevent issues.
GOOD:
upstream { server http://10.48.41.12;}server { listen 127.0.0.16:80; # [...]}由于SSLv3的POODLE 漏洞，建議使用在SSL網站禁用，僅僅使用TLS協議代替
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
原文：https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
新聞熱點
疑難解答
