Nginx add_header instruction example analysis
Preface
As we all know, the nginx configuration file sets the response header by using the add_header directive.
Use curl to check the information of a site and find that the returned header is different from what was expected:
http/2 200 date: thu, 07 feb 2019 04:26:38 gmt content-type: text/html; charset=utf-8 vary: accept-encoding, cookie cache-control: max-age=3, must-revalidate last-modified: thu, 07 feb 2019 03:54:54 gmt x-cache: miss server: cloudflare ...
The main site has configured hsts and other headers in nginx.conf:
add_header strict-transport-security "max-age=63072000; preload"; add_header x-frame-options sameorigin; add_header x-content-type-options nosniff; add_header x-xss-protection "1; mode=block";
But the response header does not have these headers. In addition to the regular headers, there is only one header x-cache configured in the location.
The first impression is that CDN filters these headers? So I looked for cloudflare's documentation, but I didn't find that it would handle these. Then I thought about it, what does CDN do to filter these? Are you full after eating? They don't do the censorship thing!
The problem shifts to the configuration of nginx. Open Google and search for "nginx location add_header", and you will find many flaws. Click on the add_header document on the official website and there is this description (other information has been omitted):
there could be several add_header directives. these directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.
Attention is focused on "these directives are inherited from the previous level if and only if there are no add_header directives defined on the current level.". That is: the parent settings will be inherited only if there is no add_header directive in the current level. So my question is clear: there is add_header in location, and the configuration in nginx.conf is discarded.
This is a deliberate behavior of nginx, and it cannot be said to be a bug or a pit. But if you understand this sentence deeply, you will find a more interesting phenomenon: only the latest add_header works. add_header can be configured in http, server and location, but the closest configuration will take effect, and all configurations above will be invalid.
But the problem doesn’t stop there. If the location is rewritten to another location, only the second header will appear in the final result. For example:
location /foo1 { add_header foo1 1; rewrite / /foo2; } location /foo2 { add_header foo2 1; return 200 "ok"; }
Regardless of requesting /foo1 or /foo2, the final header is only foo2:
Although it makes sense, this is normal behavior, but it always makes people It feels a bit forced and uncomfortable: the server loses the http configuration, and the location loses the server configuration, but the two locations are at the same level!
You cannot inherit the parent configuration, and you don’t want to repeat instructions in the current block. The solution can be to use the include instruction.
The above is the detailed content of Nginx add_header instruction example analysis. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics



How to fix Nginx 403 Forbidden error? Check file or directory permissions; 2. Check .htaccess file; 3. Check Nginx configuration file; 4. Restart Nginx. Other possible causes include firewall rules, SELinux settings, or application issues.

How to confirm whether Nginx is started: 1. Use the command line: systemctl status nginx (Linux/Unix), netstat -ano | findstr 80 (Windows); 2. Check whether port 80 is open; 3. Check the Nginx startup message in the system log; 4. Use third-party tools, such as Nagios, Zabbix, and Icinga.

The server does not have permission to access the requested resource, resulting in a nginx 403 error. Solutions include: Check file permissions. Check the .htaccess configuration. Check nginx configuration. Configure SELinux permissions. Check the firewall rules. Troubleshoot other causes such as browser problems, server failures, or other possible errors.

Answer to the question: 304 Not Modified error indicates that the browser has cached the latest resource version of the client request. Solution: 1. Clear the browser cache; 2. Disable the browser cache; 3. Configure Nginx to allow client cache; 4. Check file permissions; 5. Check file hash; 6. Disable CDN or reverse proxy cache; 7. Restart Nginx.

Steps to start Nginx in Linux: Check whether Nginx is installed. Use systemctl start nginx to start the Nginx service. Use systemctl enable nginx to enable automatic startup of Nginx at system startup. Use systemctl status nginx to verify that the startup is successful. Visit http://localhost in a web browser to view the default welcome page.

How to configure Nginx in Windows? Install Nginx and create a virtual host configuration. Modify the main configuration file and include the virtual host configuration. Start or reload Nginx. Test the configuration and view the website. Selectively enable SSL and configure SSL certificates. Selectively set the firewall to allow port 80 and 443 traffic.

There are two ways to solve the Nginx cross-domain problem: modify the cross-domain response header: add directives to allow cross-domain requests, specify allowed methods and headers, and set cache time. Use CORS modules: Enable modules and configure CORS rules that allow cross-domain requests, methods, headers, and cache times.

The methods to view the running status of Nginx are: use the ps command to view the process status; view the Nginx configuration file /etc/nginx/nginx.conf; use the Nginx status module to enable the status endpoint; use monitoring tools such as Prometheus, Zabbix, or Nagios.
