I investigated the error setting method of famous nginx when developing a WEB server, so I summarized it. nginx can return a static error to the user when an error occurs. Here's how to make the error original.
apt install nginx
Just install with.
Normally, the error is controlled by python, but nginx may return the error due to timeout etc. At that time, by default, the characters nginx are included in the error wording, which may cause a security problem or break the uniformity of the entire system, so you may want to return the original error. This is possible by modifying the server context in /etc/nginx/nginx.conf
or
/etc/nginx/conf.d/xxx.conf```.
When returning the original html file or json file to the user, set the original file setting and http status and the association of the original file in the server context.
The format of the settings in the original file looks like this.
location = /Setting name(file name) {
root The path where the original html is stored
}
The format of associating http status with the original html is as follows.
error_page http status/Setting name(file name);
The whole conf file looks like this. Now when nginx returns 500, 502, 503, 504, /flask/nginx/50x.html will be returned to the user.
sample.conf
server {
listen 8010;
server_name original;
limit_conn servers 2;
location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}
#http status and 50x.Link html settings
error_page 500 502 503 504 /50x.html;
# 50x.html settings
location = /50x.html {
#Path where html is stored
root /flask/nginx;
}
}
In the above case, the http status will be returned to the user as it occurred, but in some cases you may want to specify the status as well. This can be achieved by changing the linking settings. In this case, be careful not to put a space between = and http status.
The format of associating the http status with the original file is as follows.
error_page http status=Http status you want to return/Setting name(file name);
The whole conf file looks like this. Now when nginx returns 500, 502, 503, 504, http status 500, /flask/nginx/50x.html will be returned to the user.
sample.conf
server {
listen 8010;
server_name original;
limit_conn servers 2;
location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}
#http status and return status, 50x.Link html settings
error_page 500 502 503 504 =500 /50x.html;
# 50x.html settings
location = /50x.html {
#Path where html is stored
root /flask/nginx;
}
}
You can also put the return value in a simple text or conf file instead of a file. In that case, link the original setting with the http status and the setting in the server context.
The format of the error setting is as follows.
location = /Setting name{
return Message to return;
}
The format of linking http status and settings is as follows.
error_page http status/Setting name;
The whole conf file looks like this. Now when nginx returns 500, 502, 503, 504, an "original error" will be returned to the user.
sample.conf
server {
listen 8010;
server_name original;
limit_conn servers 2;
location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}
#Associate http status with 50x settings
error_page 500 502 503 504 /50x;
#50x setting
location = /50x {
#Message to return
return "Original error";
}
}
In the above case, the http status will be returned to the user as it occurred, but in some cases you may want to specify the status as well. This can be achieved by changing the error settings.
The format of the error setting is as follows.
location = /Setting name{
return http status to return Message to return;
}
The whole conf file looks like this. Now when nginx returns 500, 502, 503, 504, http status 500, "original error" will be returned to the user.
sample.conf
server {
listen 8010;
server_name original;
limit_conn servers 2;
location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/uwsgi.sock;
}
#Associate http status with 50x settings
error_page 500 502 503 504 /50x;
#50x setting
location = /50x {
#Message to return
return 500 "Original error";
}
}
I summarized how to control errors with nginx. Since nginx has various functions, I think that there are many opportunities to return an error. In that case, if you unify the error format, it will be easy to see and cool, so if you are particular about it, you should stick to it.
Recommended Posts