nginx 常用优化

本文档提供了Nginx的全面配置与优化指南,包括性能提升、安全性增强及常见问题解决方案。涵盖SSL/TLS最佳实践、日志分析、防火墙设置及资源保护等关键主题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


Nginx Quick Reference



My notes about Nginx...



<img src="https://img.shields.io/badge/Branch-master-green.svg?longCache=true"
    alt="Branch">


<img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg?longCache=true"
    alt="Pull Requests">


<img src="https://img.shields.io/badge/License-GNU-blue.svg?longCache=true"
    alt="License">



Created by
trimstray and
contributors




Table of Contents

Introduction

nginx_logo.png

Before using the Nginx please read Beginner’s Guide.

Nginx (/ˌɛndʒɪnˈɛks/ EN-jin-EKS) is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev. For a long time, it has been running on many heavily loaded Russian sites including Yandex, Mail.Ru, VK, and Rambler.

To increase your knowledge, read Nginx Documentation.

General disclaimer

This is not an official handbook. Many of these rules refer to external resources. It is rather a quick collection of some rules used by me in production environments (not only).

Before you start remember about the two most important things:

Do not follow guides just to get 100% of something. Think about what you actually do at your server!

These guidelines provides recommendations for very restrictive setup.

Contributing

If you find something which doesn't make sense, or one of these doesn't seem right, or something seems really stupid; please make a pull request or please add valid and well-reasoned opinions about your changes or comments.

Before add pull request please see this.

SSL Report: blkcipher.info

Many of these recipes have been applied to the configuration of my private website. I finally got all 100%'s on my scores:

<img src="https://github.com/trimstray/nginx-quick-reference/blob/master/doc/img/blkcipher_ssllabs_preview.png"
    alt="blkcipher_ssllabs_preview">

An example configuration is in this chapter.

Printable high-res hardening checklist

Hardening checklist based on this recipes (@ssllabs A+ 100%) - High-Res 5000x8200.

For *.xcf and *.pdf formats please see this directory.

<img src="https://github.com/trimstray/nginx-quick-reference/blob/master/doc/img/nginx-hardening-checklist.png"
    alt="nginx-hardening-checklist" width="75%" height="75%">

External Resources

About Nginx


  :black_small_square: Nginx Project

  :black_small_square: Nginx Documentation

  :black_small_square: Nginx official read-only mirror

References


  :black_small_square: Nginx boilerplate configs

  :black_small_square: Awesome Nginx configuration template

  :black_small_square: A collection of resources covering Nginx and more

  :black_small_square: Nginx Secure Web Server

  :black_small_square: Emiller’s Guide To Nginx Module Development

Cheatsheets


  :black_small_square: Nginx Cheatsheet

  :black_small_square: Nginx Quick Reference

  :black_small_square: Nginx Cheatsheet by Mijdert Stuij

Performance & Hardening


  :black_small_square: SSL/TLS Deployment Best Practices

  :black_small_square: SSL Server Rating Guide

  :black_small_square: How to Build a Tough NGINX Server in 15 Steps

  :black_small_square: Top 25 Nginx Web Server Best Security Practices

  :black_small_square: Strong SSL Security on Nginx

  :black_small_square: Nginx Tuning For Best Performance by Denji

  :black_small_square: Enable cross-origin resource sharing (CORS)

  :black_small_square: TLS has exactly one performance problem: it is not used widely enough

  :black_small_square: WAF for Nginx

  :black_small_square: ModSecurity for Nginx

  :black_small_square: Transport Layer Protection Cheat Sheet

  :black_small_square: Security/Server Side TLS

Config generators


  :black_small_square: Nginx config generator on steroids

Static analyzers


  :black_small_square: Nginx static analyzer

Log analyzers


  :black_small_square: GoAccess

  :black_small_square: Graylog

  :black_small_square: Logstash

Performance analyzers


  :black_small_square: ngxtop

Benchmarking tools


  :black_small_square: siege

  :black_small_square: wrk

  :black_small_square: bombardier

  :black_small_square: gobench

Online tools


  :black_small_square: SSL Server Test by SSL Labs

  :black_small_square: SSL/TLS Capabilities of Your Browser

  :black_small_square: Test SSL/TLS (PCI DSS, HIPAA and NIST)

  :black_small_square: SSL analyzer and certificate checker

  :black_small_square: Test your TLS server configuration (e.g. ciphers)

  :black_small_square: Scan your website for non-secure content

  :black_small_square: Strong ciphers for Apache, Nginx, Lighttpd and more

  :black_small_square: Analyse the HTTP response headers by Security Headers

  :black_small_square: Analyze your website by Mozilla Observatory

  :black_small_square: Linting tool that will help you with your site's accessibility, speed, security and more

  :black_small_square: Service to scan and analyse websites

  :black_small_square: Online tool to learn, build, & test Regular Expressions

  :black_small_square: Online Regex Tester & Debugger

  :black_small_square: User agent compatibility (Cipher suite)

Other stuff


  :black_small_square: BBC Digital Media Distribution: How we improved throughput by 4x

  :black_small_square: Web cache server performance benchmark: nuster vs nginx vs varnish vs squid

Helpers

Shell aliases
alias ng.test='nginx -t -c /etc/nginx/nginx.conf'
alias ng.stop='ng.test && systemctl stop nginx'
alias ng.reload='ng.test && systemctl reload nginx'
alias ng.restart='ng.test && systemctl restart nginx'
# or
alias ng.restart='ng.test && kill -HUP `cat /var/run/nginx.pid`'
Debugging
See the top 5 IP addresses in a web server log
cut -d ' ' -f1 /path/to/logfile | sort | uniq -c | sort -nr | head -5 | nl
Analyse web server log and show only 2xx http codes
tail -n 100 -f /path/to/logfile | grep "HTTP/[1-2].[0-1]\" [2]"
Analyse web server log and show only 5xx http codes
tail -n 100 -f /path/to/logfile | grep "HTTP/[1-2].[0-1]\" [5]"
Get range of dates in a web server log
# 1)
awk '/'$(date -d "1 hours ago" "+%d\\/%b\\/%Y:%H:%M")'/,/'$(date "+%d\\/%b\\/%Y:%H:%M")'/ { print $0 }' /path/to/logfile

# 2)
awk '/05\/Feb\/2019:09:2.*/,/05\/Feb\/2019:09:5.*/' /path/to/logfile
Get line rates from web server log
tail -F /path/to/logfile | pv -N RAW -lc 1>/dev/null
Trace network traffic for all Nginx processes
strace -e trace=network -p `pidof nginx | sed -e 's/ /,/g'`
List all files accessed by a Nginx
strace -ff -e trace=file nginx 2>&1 | perl -ne 's/^[^"]+"(([^\\"]|\\[\\"nt])*)".*/$1/ && print'

Base rules

:beginner: Organising Nginx configuration
Rationale

When your configuration grow, the need for organising your code will also grow. Well organised code is:

  • easier to understand
  • easier to maintain
  • easier to work with

Use include directive to attach your Nginx specific code to global config, contexts and other.

Example
# Store this configuration in e.g. https-ssl-common.conf
listen 10.240.20.2:443 ssl;

root /etc/nginx/error-pages/other;

ssl_certificate /etc/nginx/domain.com/certs/nginx_domain.com_bundle.crt;
ssl_certificate_key /etc/nginx/domain.com/certs/domain.com.key;

# And include this file in server section:
server {

  include /etc/nginx/domain.com/commons/https-ssl-common.conf;

  server_name domain.com www.domain.com;

  ...
External resources
:beginner: Separate listen directives for 80 and 443
Rationale

...

Example
# For http:
server {

  listen 10.240.20.2:80;

  ...

}

# For https:
server {

  listen 10.240.20.2:443 ssl;

  ...

}
External resources
:beginner: Prevent processing requests with undefined server names
Rationale

Nginx should prevent processing requests with undefined server names - also traffic on IP address. It also protects against configuration errors and don't pass traffic to incorrect backends. The problem is easily solved by creating a default catch all server config.

If none of the listen directives have the default_server parameter then the first server with the address:port pair will be the default server for this pair.

If someone makes a request using an IP address instead of a server name, the Host request header field will contain the IP address and the request can be handled using the IP address as the server name.

I think the best solution is return 444; for default server name because this will close the connection and log it internally, for any domain that isn't defined in Nginx.

Example
# Place it at the beginning of the configuration file to prevent mistakes.
server {

  # Add default_server to your listen directive in the server that you want to act as the default.
  listen 10.240.20.2:443 default_server ssl;

  # We catch invalid domain names, requests without the "Host" header and all others (also due to the above setting).
  server_name _ "" default_server;

  ...

  return 444;

  # We can also serve:
  # location / {

    # static file (error page):
    # root /etc/nginx/error-pages/404;
    # or redirect:
    # return 301 https://badssl.com;

    # return 444;

  # }

}

server {

  listen 10.240.20.2:443 ssl;

  server_name domain.com;

  ...

}

server {

  listen 10.240.20.2:443 ssl;

  server_name domain.org;

  ...

}
External resources
:beginner: Use only one SSL config for specific listen directive
Rationale

For sharing a single IP address between several HTTPS servers you should use one SSL config (e.g. protocols, ciphers, curves) because changes will affect the default server.

Remember that regardless of ssl parameters, you are able to use multiple SSL certificates.

If you want to set up different SSL configurations for the same IP address then it will fail. It's important because SSL configuration is presented for default server - if none of the listen directives have the default_server parameter then the first server in your configuration. So you should use only one SSL setup with several names on the same IP address.

Example
# Store this configuration in e.g. https.conf
listen 192.168.252.10:443 default_server ssl http2;

ssl_protocols TLSv1.2;
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";

ssl_prefer_server_ciphers on;

ssl_ecdh_curve secp521r1:secp384r1;

...

# Include this file to the server context (attach domain-a.com for specific listen directive)
server {

  include /etc/nginx/https.conf;

  server_name domain-a.com;

  ...

}

# Include this file to the server context (attach domain-b.com for specific listen directive)
server {

  include /etc/nginx/https.conf;

  server_name domain-b.com;

  ...

}
External resources
:beginner: Force all connections over TLS
Rationale

You should always use HTTPS instead of HTTP to protect your website, even if it doesn’t handle sensitive communications.

Example
server {

  listen 10.240.20.2:80;

  server_name domain.com;

  return 301 https://$host$request_uri;

}

server {

  listen 10.240.20.2:443 ssl;

  server_name domain.com;

  ...

}
External resources
:beginner: Use geo/map modules instead allow/deny
Rationale

Creates variables with values depending on the client IP address. Use map or geo modules (one of them) to prevent users abusing your servers.

Example
# Map module:
map $remote_addr $globals_internal_map_acl {

  # Status code:
  #  - 0 = false
  #  - 1 = true
  default 0;

  ### INTERNAL ###
  10.255.10.0/24 1;
  10.255.20.0/24 1;
  10.255.30.0/24 1;
  192.168.0.0/16 1;

}

# Geo module:
geo $globals_internal_geo_acl {

  # Status code:
  #  - 0 = false
  #  - 1 = true
  default 0;

  ### INTERNAL ###
  10.255.10.0/24 1;
  10.255.20.0/24 1;
  10.255.30.0/24 1;
  192.168.0.0/16 1;

}
External resources
:beginner: Map all the things...
Rationale

Map module provides a more elegant solution for clearly parsing a big list of regexes, e.g. User-Agents. Manage a large number of redirects with Nginx maps.

Example
map $http_user_agent $device_redirect {

  default "desktop";

  ~(?i)ip(hone|od) "mobile";
  ~(?i)android.*(mobile|mini) "mobile";
  ~Mobile.+Firefox "mobile";
  ~^HTC "mobile";
  ~Fennec "mobile";
  ~IEMobile "mobile";
  ~BB10 "mobile";
  ~SymbianOS.*AppleWebKit "mobile";
  ~Opera\sMobi "mobile";

}

if ($device_redirect = "mobile") {

  return 301 https://m.domain.com$request_uri;

}
External resources
:beginner: Drop the same root inside location block
Rationale

If you add a root to every location block then a location block that isn’t matched will have no root. Set global root inside server directive.

Example
server {

  server_name domain.com;

  root /var/www/domain.com/public;

  location / {

    ...

  }

  location /api {

    ...

  }

  location /static {

    root /var/www/domain.com/static;

    ...

  }

}
External resources
:beginner: Use debug mode for debugging
Rationale

The error_log directive is part of the core module.

There's probably more detail than you want, but that can sometimes be a lifesaver (but log file growing rapidly on a very high-traffic sites).

Example
rewrite_log on;
error_log /var/log/nginx/error-debug.log debug;
External resources
:beginner: Use custom log formats
Rationale

The access_log directive is part of the HttpLogModule.

Anything you can access as a variable in nginx config, you can log, including non-standard http headers, etc. so it's a simple way to create your own log format for specific situations.

Example
# Default main log format from nginx repository:
log_format main
                '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"';

# Extended main log format:
log_format main-level-0
                '$remote_addr - $remote_user [$time_local] '
                '"$request_method $scheme://$host$request_uri '
                '$server_protocol" $status $body_bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '$request_time';

# Debug log formats:
log_format debug-level-0
                '$remote_addr - $remote_user [$time_local] '
                '"$request_method $scheme://$host$request_uri '
                '$server_protocol" $status $body_bytes_sent '
                '$request_id $pid $msec $request_time '
                '$upstream_connect_time $upstream_header_time '
                '$upstream_response_time "$request_filename" '
                '$request_completion';

log_format debug-level-1
                '$remote_addr - $remote_user [$time_local] '
                '"$request_method $scheme://$host$request_uri '
                '$server_protocol" $status $body_bytes_sent '
                '$request_id $pid $msec $request_time '
                '$upstream_connect_time $upstream_header_time '
                '$upstream_response_time "$request_filename" $request_length '
                '$request_completion $connection $connection_requests';

log_format debug-level-2
                '$remote_addr - $remote_user [$time_local] '
                '"$request_method $scheme://$host$request_uri '
                '$server_protocol" $status $body_bytes_sent '
                '$request_id $pid $msec $request_time '
                '$upstream_connect_time $upstream_header_time '
                '$upstream_response_time "$request_filename" $request_length '
                '$request_completion $connection $connection_requests '
                '$server_addr $server_port $remote_addr $remote_port';
External resources

Performance

:beginner: Adjust worker processes
Rationale

The worker_processes directive is the sturdy spine of life for Nginx. This directive is responsible for letting our virtual server know many workers to spawn once it has become bound to the proper IP and port(s).

Official Nginx documentation say:

When one is in doubt, setting it to the number of available CPU cores would be a good start (the value "auto" will try to autodetect it).

I think for high load proxy servers (also standalone servers) good value is ALL_CORES - 1 (please test it before used).

Example
# VCPU = 4 , expr $(nproc --all) - 1
worker_processes 3;
External resources
:beginner: Use HTTP/2
Rationale

HTTP/2 will make our applications faster, simpler, and more robust.

The primary goals for HTTP/2 are to reduce latency by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields, and add support for request prioritization and server push.

HTTP/2 is backwards-compatible with HTTP/1.1, so it would be possible to ignore it completely and everything will continue to work as before.

Example
# For https:
server {

  listen 10.240.20.2:443 ssl http2;

  ...
External resources
:beginner: Maintaining SSL Sessions
Rationale

This improves performance from the clients’ perspective, because it eliminates the need for a new (and time-consuming) SSL handshake to be conducted each time a request is made.

Most servers do not purge sessions or ticket keys, thus increasing the risk that a server compromise would leak data from previous (and future) connections.

Example
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 24h;
ssl_session_tickets off;
ssl_buffer_size 1400;
External resources
:beginner: Use exact names where possible
Rationale

Exact names, wildcard names starting with an asterisk, and wildcard names ending with an asterisk are stored in three hash tables bound to the listen ports.

The exact names hash table is searched first. If a name is not found, the hash table with wildcard names starting with an asterisk is searched. If the name is not found there, the hash table with wildcard names ending with an asterisk is searched. Searching wildcard names hash table is slower than searching exact names hash table because names are searched by domain parts.

Regular expressions are tested sequentially and therefore are the slowest method and are non-scalable. For these reasons, it is better to use exact names where possible.

Example
# It is more efficient to define them explicitly:
server {

    listen       80;

    server_name  example.org  www.example.org  *.example.org;

    ...

}

# than to use the simplified form:
server {

    listen       80;

    server_name  .example.org;

    ...

}
External resources

Hardening

:beginner: Run as an unprivileged user
Rationale

There is no real difference in security just by changing the process owner name. On the other hand in security, the principle of least privilege states that an entity should be given no more permission than necessary to accomplish its goals within a given system. This way only master process runs as root.

Example
# Edit nginx.conf:
user www-data;

# Set owner and group for root (app, default) directory:
chown -R www-data:www-data /var/www/domain.com
External resources
:beginner: Disable unnecessary modules
Rationale

It is recommended to disable any modules which are not required as this will minimize the risk of any potential attacks by limiting the operations allowed by the web server.

Example
# During installation:
./configure --without-http_autoindex_module

# Comment modules in the configuration file e.g. modules.conf:
# load_module                 /usr/share/nginx/modules/ndk_http_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_auth_pam_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_cache_purge_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_dav_ext_module.so;
load_module                   /usr/share/nginx/modules/ngx_http_echo_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_fancyindex_module.so;
load_module                   /usr/share/nginx/modules/ngx_http_geoip_module.so;
load_module                   /usr/share/nginx/modules/ngx_http_headers_more_filter_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_image_filter_module.so;
# load_module                 /usr/share/nginx/modules/ngx_http_lua_module.so;
load_module                   /usr/share/nginx/modules/ngx_http_perl_module.so;
# load_module                 /usr/share/nginx/modules/ngx_mail_module.so;
# load_module                 /usr/share/nginx/modules/ngx_nchan_module.so;
# load_module                 /usr/share/nginx/modules/ngx_stream_module.so;
External resources
:beginner: Protect sensitive resources
Rationale

Hidden directories and files should never be web accessible.

Example
if ($request_uri ~ "/\.git") {

  return 403;

}

# or
location ~ /\.git {

  deny all;

}

# or
location ~* ^.*(\.(?:git|svn|htaccess))$ {

  return 403;

}

# or all . directories/files in general (but remember about .well-known path)
location ~ /\. {

  deny all;

}
External resources
:beginner: Hide Nginx version number
Rationale

Disclosing the version of Nginx running can be undesirable, particularly in environments sensitive to information disclosure.

The "Official Apache Documentation (Apache Core Features)" say:

Setting ServerTokens to less than minimal is not recommended because it makes it more difficult to debug interoperational problems. Also note that disabling the Server: header does nothing at all to make your server more secure. The idea of "security through obscurity" is a myth and leads to a false sense of safety.

Example
server_tokens off;
External resources
:beginner: Hide Nginx server signature
Rationale

In my opinion there is no real reason or need to show this much information about your server. It is easy to look up particular vulnerabilities once you know the version number.

You should compile Nginx from sources with ngx_headers_more to used more_set_headers directive.

Example
more_set_headers "Server: Unknown";
External resources
:beginner: Hide upstream proxy headers
Rationale

When Nginx is used to proxy requests to an upstream server (such as a PHP-FPM instance), it can be beneficial to hide certain headers sent in the upstream response (for example, the version of PHP running).

Example
proxy_hide_header X-Powered-By;
proxy_hide_header X-AspNetMvc-Version;
proxy_hide_header X-AspNet-Version;
proxy_hide_header X-Drupal-Cache;
External resources
:beginner: Use only 4096-bit private keys
Rationale

Advisories recommend 2048 for now. Security experts are projecting that 2048 bits will be sufficient for commercial use until around the year 2030.

Generally there is no compelling reason to choose 4096 bit keys over 2048 provided you use sane expiration intervals.

If you want to get A+ with 100%s on SSL Lab you should definitely use 4096 bit private key.

I always generate 4096 bit keys for low busy sites since the downside is minimal (slightly lower performance) and security is slightly higher (although not as high as one would like).

Use of alternative solution: ECC Certificate Signing Request (CSR).

The "SSL/TLS Deployment Best Practices" book say:

The cryptographic handshake, which is used to establish secure connections, is an operation whose cost is highly influenced by private key size. Using a key that is too short is insecure, but using a key that is too long will result in “too much” security and slow operation. For most web sites, using RSA keys stronger than 2048 bits and ECDSA keys stronger than 256 bits is a waste of CPU power and might impair user experience. Similarly, there is little benefit to increasing the strength of the ephemeral key exchange beyond 2048 bits for DHE and 256 bits for ECDHE.

Konstantin Ryabitsev (Reddit):

Generally speaking, if we ever find ourselves in a world where 2048-bit keys are no longer good enough, it won't be because of improvements in brute-force capabilities of current computers, but because RSA will be made obsolete as a technology due to revolutionary computing advances. If that ever happens, 3072 or 4096 bits won't make much of a difference anyway. This is why anything above 2048 bits is generally regarded as a sort of feel-good hedging theatre.

Example
### Example (RSA):
( _fd="domain.com.key" ; _len="4096" ; openssl genrsa -out ${_fd} ${_len} )

# Let's Encrypt:
certbot certonly -d domain.com -d www.domain.com --rsa-key-size 4096

### Example (ECC):
# _curve: prime256v1, secp521r1, secp384r1
( _fd="domain.com.key" ; _fd_csr="domain.com.csr" ; _curve="prime256v1" ; \
openssl ecparam -out ${_fd} -name ${_curve} -genkey ; openssl req -new -key ${_fd} -out ${_fd_csr} -sha256 )

# Let's Encrypt (from above):
certbot --csr ${_fd_csr} -[other-args]

For x25519:

( _fd="private.key" ; _curve="x25519" ; \
openssl genpkey -algorithm ${_curve} -out ${_fd} )

  ssllabs score: 100

( _fd="domain.com.key" ; _len="2048" ; openssl genrsa -out ${_fd} ${_len} )

# Let's Encrypt:
certbot certonly -d domain.com -d www.domain.com

  ssllabs score: 90

External resources
:beginner: Keep only TLS 1.2 (+ TLS 1.3)
Rationale

It is recommended to run TLS 1.1/1.2 and fully disable SSLv2, SSLv3 and TLS 1.0 that have protocol weaknesses.

TLS 1.1 and 1.2 are both without security issues - but only v1.2 provides modern cryptographic algorithms. TLS 1.0 and TLS 1.1 protocols will be removed from browsers at the beginning of 2020.

Example
ssl_protocols TLSv1.2;

# For TLS 1.3
ssl_protocols TLSv1.2 TLSv1.3;

  ssllabs score: 100

ssl_protocols TLSv1.2 TLSv1.1;

  ssllabs score: 95

External resources
:beginner: Use only strong ciphers
Rationale

This parameter changes quite often, the recommended configuration for today may be out of date tomorrow.

For more security use only strong and not vulnerable ciphersuite (but if you use http/2 you can get Server sent fatal alert: handshake_failure error).

Place ECDHE and DHE suites at the top of your list. The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.

For backward compatibility software components you should use less restrictive ciphers.

You should definitely disable weak ciphers like those with DSS, DSA, DES/3DES, RC4, MD5, SHA1, null, anon in the name.

Example
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384";

  ssllabs score: 100

# 1)
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256";

# 2)
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:!AES256-GCM-SHA256:!AES256-GCM-SHA128:!aNULL:!MD5";

  ssllabs score: 90

Ciphersuite for TLS 1.3:

ssl_ciphers "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256";
External resources
:beginner: Use more secure ECDH Curve
Rationale

For a SSL server certificate, an "elliptic curve" certificate will be used only with digital signatures (ECDSA algorithm).

x25519 is a more secure but slightly less compatible option. To maximise interoperability with existing browsers and servers, stick to P-256 prime256v1 and P-384 secp384r1 curves.

NSA Suite B says that NSA uses curves P-256 and P-384 (in OpenSSL, they are designated as, respectively, "prime256v1" and "secp384r1"). There is nothing wrong with P-521, except that it is, in practice, useless. Arguably, P-384 is also useless, because the more efficient P-256 curve already provides security that cannot be broken through accumulation of computing power.

Use P-256 to minimize trouble. If you feel that your manhood is threatened by using a 256-bit curve where a 384-bit curve is available, then use P-384: it will increases your computational and network costs.

If you do not set ssh_ecdh_curve, then the Nginx will use its default settings, e.g. chrome will prefer x25519, but this is not recommended because you can not control the Nginx's default settings (seems to be P-256).

Explicitly set ssh_ecdh_curve X25519:prime256v1:secp521r1:secp384r1; decreases the Key Exchange SSL Labs rating.

Definitely do not use the secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1 curves. They have a too small size for security application according to NIST recommendation.

Example
ssl_ecdh_curve secp521r1:secp384r1;

  ssllabs score: 100

# Alternative (this one doesn’t affect compatibility, by the way; it’s just a question of the preferred order). This setup downgrade Key Exchange score:
ssl_ecdh_curve X25519:prime256v1:secp521r1:secp384r1;
External resources
:beginner: Use strong Key Exchange
Rationale

The DH key is only used if DH ciphers are used. Modern clients prefer ECDHE instead and if your Nginx accepts this preference then the handshake will not use the DH param at all since it will not do a DHE key exchange but an ECDHE key exchange.

Most of the "modern" profiles from places like Mozilla's ssl config generator no longer recommend using this.

Default key size in OpenSSL is 1024 bits - it's vulnerable and breakable. For the best security configuration use your own 4096 bit DH Group or use known safe ones pre-defined DH groups (it's recommended) from mozilla.

Example
# To generate a DH key:
openssl dhparam -out /etc/nginx/ssl/dhparam_4096.pem 4096

# To produce "DSA-like" DH parameters:
openssl dhparam -dsaparam -out /etc/nginx/ssl/dhparam_4096.pem 4096

# To generate a ECDH key:
openssl ecparam -out /etc/nginx/ssl/ecparam.pem -name prime256v1

# Nginx configuration:
ssl_dhparam /etc/nginx/ssl/dhparams_4096.pem;

  ssllabs score: 100

External resources
:beginner: Defend against the BEAST attack
Rationale

Enables server-side protection from BEAST attacks.

Example
ssl_prefer_server_ciphers on;
External resources
:beginner: Disable HTTP compression (mitigation of CRIME/BREACH attacks)
Rationale

You should probably never use TLS compression. Some user agents (at least Chrome) will disable it anyways. Disabling SSL/TLS compression stops the attack very effectively.

Some attacks are possible because of gzip (HTTP compression not TLS compression) being enabled on SSL requests. In most cases, the best action is to simply disable gzip for SSL.

You shouldn't use HTTP compression on private responses when using TLS.

Compression can be (i think) okay to HTTP compress publicly available static content like css or js and HTML content with zero sensitive info (like an "About Us" page).

Example
gzip off;
External resources
:beginner: HTTP Strict Transport Security
Rationale

The header indicates for how long a browser should unconditionally refuse to take part in unsecured HTTP connection for a specific domain.

Example
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains" always;

  ssllabs score: A+

External resources
:beginner: Reduce XSS risks (Content-Security-Policy)
Rationale

CSP reduce the risk and impact of XSS attacks in modern browsers.

Example
# This policy allows images, scripts, AJAX, and CSS from the same origin, and does not allow any other resources to load.
add_header Content-Security-Policy "default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self';" always;
External resources
:beginner: Control the behavior of the Referer header (Referrer-Policy)
Rationale

Determine what information is sent along with the requests.

Example
add_header Referrer-Policy "no-referrer";
External resources
:beginner: Provide clickjacking protection (X-Frame-Options)
Rationale

Helps to protect your visitors against clickjacking attacks. It is recommended that you use the x-frame-options header on pages which should not be allowed to render a page in a frame.

Example
add_header X-Frame-Options "SAMEORIGIN" always;
External resources
:beginner: Prevent some categories of XSS attacks (X-XSS-Protection)
Rationale

Enable the cross-site scripting (XSS) filter built into modern web browsers.

Example
add_header X-XSS-Protection "1; mode=block" always;
External resources
:beginner: Prevent Sniff Mimetype middleware (X-Content-Type-Options)
Rationale

It prevents the browser from doing MIME-type sniffing (prevents "mime" based attacks).

Example
add_header X-Content-Type-Options "nosniff" always;
External resources
:beginner: Deny the use of browser features (Feature-Policy)
Rationale

This header protects your site from third parties using APIs that have security and privacy implications, and also from your own team adding outdated APIs or poorly optimized images.

Example
add_header Feature-Policy "geolocation none; midi none; notifications none; push none; sync-xhr none; microphone none; camera none; magnetometer none; gyroscope none; speaker none; vibrate none; fullscreen self; payment none; usb none;";
External resources
:beginner: Reject unsafe HTTP methods
Rationale

Set of methods support by a resource. An ordinary web server supports the HEAD, GET and POST methods to retrieve static and dynamic content. Other (e.g. OPTIONS, TRACE) methods should not be supported on public web servers, as they increase the attack surface.

Example
add_header Allow "GET, POST, HEAD" always;

if ($request_method !~ ^(GET|POST|HEAD)$) {

  return 405;

}
External resources
:beginner: Control Buffer Overflow attacks
Rationale

Buffer overflow attacks are made possible by writing data to a buffer and exceeding that buffers’ boundary and overwriting memory fragments of a process. To prevent this in Nginx we can set buffer size limitations for all clients.

Example
client_body_buffer_size 100k;
client_header_buffer_size 1k;
client_max_body_size 100k;
large_client_header_buffers 2 1k;
External resources
:beginner: Mitigating Slow HTTP DoS attack (Closing Slow Connections)
Rationale

Close connections that are writing data too infrequently, which can represent an attempt to keep connections open as long as possible.

Example
client_body_timeout 10s;
client_header_timeout 10s;
keepalive_timeout 5s 5s;
send_timeout 10s;
External resources

Configuration examples

Remember to make a copy of the current configuration and all files/directories.

Nginx Contexts

Before read this configuration remember about Nginx Contexts structure:

Core Contexts

  Global/Main Context
    Events Context
    HTTP Context
      Server Context
        Location Context
      Upstream Context
    Mail Context

Reverse Proxy

This chapter describes the basic configuration of my proxy server (for blkcipher.info domain).

Import configuration

It's very simple - clone the repo and perform full directory sync:

git clone https://github.com/trimstray/nginx-quick-reference.git
rsync -avur --delete lib/nginx/ /etc/nginx/

For leaving your configuration (not recommended) remove --delete rsync param.

Set bind IP address
Find and replace 192.168.252.2 string in directory and file names
cd /etc/nginx
find . -depth -name '*192.168.252.2*' -execdir bash -c 'mv -v "$1" "${1//192.168.252.2/xxx.xxx.xxx.xxx}"' _ {} \;
Find and replace 192.168.252.2 string in configuration files
cd /etc/nginx
find . -type f -print0 | xargs -0 sed -i 's/192.168.252.2/xxx.xxx.xxx.xxx/g'
Set your domain name
Find and replace blkcipher.info string in directory and file names
cd /etc/nginx
find . -depth -name '*blkcipher.info*' -execdir bash -c 'mv -v "$1" "${1//blkcipher.info/example.com}"' _ {} \;
Find and replace blkcipher.info string in configuration files
cd /etc/nginx
find . -type f -print0 | xargs -0 sed -i 's/blkcipher_info/example_com/g'
find . -type f -print0 | xargs -0 sed -i 's/blkcipher.info/example.com/g'
Regenerate private keys and certs
For localhost
cd /etc/nginx/master/_server/localhost/certs
# Private key + Self-signed certificate
( _fd="localhost.key" ; _fd_crt="nginx_localhost_bundle.crt" ; \
openssl req -x509 -newkey rsa:4096 -keyout ${_fd} -out ${_fd_crt} -days 365 -nodes \
-subj "/C=X0/ST=localhost/L=localhost/O=localhost/OU=X00/CN=localhost" )
For default_server
cd /etc/nginx/master/_server/defaults/certs
# Private key + Self-signed certificate
( _fd="defaults.key" ; _fd_crt="nginx_defaults_bundle.crt" ; \
openssl req -x509 -newkey rsa:4096 -keyout ${_fd} -out ${_fd_crt} -days 365 -nodes \
-subj "/C=X1/ST=default/L=default/O=default/OU=X11/CN=default_server" )
For your domain (e.g. Let's Encrypt)
cd /etc/nginx/master/_server/example.com/certs

# For multidomain:
certbot certonly -d example.com -d www.example.com --rsa-key-size 4096

# For wildcard:
certbot certonly --manual --preferred-challenges=dns -d example.com -d *.example.com --rsa-key-size 4096

# Copy private key and chain:
cp /etc/letsencrypt/live/example.com/fullchain.pem nginx_example.com_bundle.crt
cp /etc/letsencrypt/live/example.com/privkey.pem example.com.key
Add new domain
Updated nginx.conf
# At the end of the file (in 'IPS/DOMAINS' section)
include /etc/nginx/master/_server/domain.com/servers.conf;
include /etc/nginx/master/_server/domain.com/backends.conf;
Init domain directory
cd /etc/nginx/cd master/_server
cp -R example.com domain.com
cd domain.com
find . -depth -name '*example.com*' -execdir bash -c 'mv -v "$1" "${1//example.com/domain.com}"' _ {} \;
find . -type f -print0 | xargs -0 sed -i 's/example_com/domain_com/g'
find . -type f -print0 | xargs -0 sed -i 's/example.com/domain.com/g'
Test your configuration
nginx -t -c /etc/nginx/nginx.conf
### Nginx 常用配置示例与参数说明 #### 1. server 块中的常用参数 `server` 是 Nginx 中用于定义虚拟主机的关键部分,以下是常用的 `server` 参数及其作用: - **listen**: 指定服务器监听的端口号。例如:`listen 80;` 表示监听 HTTP 的标准端口[^2]。 - **server_name**: 设置服务器的域名或 IP 地址。例如:`server_name example.com;` 可以绑定到特定的域名或 IP 地址。 #### 2. location 块中的常用参数 `location` 块用于匹配 URL 并应用相应的处理逻辑。常见的参数如下: - **root**: 指定网站的根目录路径。例如:`root /var/www/html;` 将 `/` 路径映射到该目录下的文件。 - **alias**: 类似于 `root`,但它会替换匹配的部分路径。例如,在子路由部署 React 应用时使用的 `alias` 配置[^1]: ```nginx location ^~ /anan/ { alias /usr/local/nginx/html/anan/; try_files $uri $uri/ /anan/index.html; index index.html; } ``` - **try_files**: 当访问某个 URI 不存在时尝试其他替代资源。例如:`try_files $uri $uri/ /anan/index.html;` 确保即使刷新页面也不会返回 404 错误[^1]。 - **index**: 设置默认索引文件名。例如:`index index.html index.htm;` 定义了当用户访问目录时不带具体文件名时加载哪些文件作为首页[^2]。 #### 3. 日志相关配置 Nginx 支持灵活的日志记录方式,可以通过以下指令实现: - **log_format**: 自定义日志格式。例如: ```nginx log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; ``` 这里定义了一个名为 `main` 的日志格式,包含了客户端地址、请求方法、状态码等信息[^4]。 - **access_log**: 记录访问日志的位置和格式。例如: ```nginx access_log /usr/local/etc/nginx/logs/host.access.log main; ``` 上述语句表示将访问日志保存至指定位置并采用之前定义好的 `main` 格式[^4]。 - **error_log**: 记录错误日志的位置和级别。例如: ```nginx error_log /home/log/nginx/www.anan.com.log warn; ``` #### 4. 性能优化相关配置 为了提升性能,通常还会加入一些额外选项: - **gzip**: 启用压缩传输来减少网络流量消耗。例如: ```nginx gzip on; ``` 此命令开启 Gzip 压缩功能。 #### 5. http 块的作用 `http` 块位于全局上下文中,主要用于封装多个 `server` 实体以及其他高级特性,比如代理转发、缓存管理、日志定制等功能。它还可以用来引入外部配置文件或者调整 MIME 类型支持范围等[^5]。 ```nginx http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root html; index index.html index.htm; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } } ``` 以上是一个典型的最小化 Nginx 配置实例,展示了如何通过组合不同层次上的指令完成基本服务搭建工作流程。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值