关于nginx:Nginx常见错误码解决方案

302谬误

景象:nginx在应用非80端口做反向代理时,浏览器拜访发现返回302谬误

解决方案:

//如果是 proxy_set_header Host $host;
//那么改成proxy_set_header Host $host:$server_post;
//没有配置则加上proxy_set_header Host $host:$server_post;

//以下为增加地位
location ^/api {

    proxy_set_header Host $host:$server_post; 
    proxy_pass http://127.0.0.1;
}

400谬误

nginx400谬误是因为request header过大,通常是因为cookie中写入了较长的字符串所引起的。若cookie太大,可能还须要调整large_client_header_buffers(默认4k)

403谬误

参考(403谬误解决)[https://rumenz.com/rumenbiji/…]

413谬误

413 Request Entity Too Large

上传文件过程中容易呈现这个问题,传递的某些数据大小超过了nginx的配置

解决方案:

hhtp{
    client_max_body_size 8M;       //扭转这个值
    client_body_buffer_size 128k; //缓冲区大小
}

如果后端是php 批改php.ini
post_max_size = 8M  
upload_max_filesize = 6M
重启php服务

如果后端是Springboot

Spring Boot 1.3.x 
multipart.maxFileSize=8M
multipart.maxRequestSize=8M

Spring Boot 1.4.x and 1.5.x
spring.http.multipart.maxFileSize=8M
spring.http.multipart.maxRequestSize=8M


Spring Boot 2.x
spring.servlet.multipart.max-file-size=8M
spring.servlet.multipart.max-request-size=8M

414谬误

414 Request-URI Too Large 申请的url太长了

解决方案:

http{
    client_header_buffer_size 512k;
    large_client_header_buffers 4 512k;
}

499谬误

这是nginx定义的一个状态码,用于示意这样的谬误:服务器返回http头之前,客户端就提前敞开了http连贯

问题的外围就是要排查为什么服务端解决工夫过长

可能问题:

1.后盾python程序处理申请工夫过长

2.mysql慢查问

通过查看监控:

1.cpu和内存的应用,都在失常范畴

2.后台程序拜访失常

3.MySQL没有慢查问

502谬误

502 Bad Gateway:作为网关或者代理工作的服务器尝试执行申请时,从上游服务器接管到有效的响应

504谬误

504 Gateway Time-out:作为网关或者代理工作的服务器尝试执行申请时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理