下载文档原格式
HTTP状态代码code（错误代码集合）返回错误代码集合100 Continue 初始的请求已经接受，客户应当继续发送请求的其余部分。
（HTTP 1.1新）101 Switching Protocols 服务器将遵从客户的请求转换到另外⼀种协议（HTTP 1.1新）200 OK ⼀切正常，对GET和POST请求的应答⽂档跟在后⾯。
201 Created 服务器已经创建了⽂档，Location头给出了它的URL。
202 Accepted 已经接受请求，但处理尚未完成。
203 Non-Authoritative Information ⽂档已经正常地返回，但⼀些应答头可能不正确，因为使⽤的是⽂档的拷贝（HTTP 1.1新）。
204 No Content 没有新⽂档，浏览器应该继续显⽰原来的⽂档。
如果⽤户定期地刷新页⾯，⽽Servlet可以确定⽤户⽂档⾜够新，这个状态代码是很有⽤的。
205 Reset Content 没有新的内容，但浏览器应该重置它所显⽰的内容。
⽤来强制浏览器清除表单输⼊内容（HTTP 1.1新）。
206 Partial Content 客户发送了⼀个带有Range头的GET请求，服务器完成了它（HTTP1.1新）。
300 Multiple Choices 客户请求的⽂档可以在多个位置找到，这些位置已经在返回的⽂档内列出。
如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently 客户请求的⽂档在其他地⽅，新的URL在Location头中给出，浏览器应该⾃动地访问新的URL。
302 Found 类似于301，但新的URL应该被视为临时性的替代，⽽不是永久性的。
注意，在HTTP1.0中对应的状态信息是“Moved Temporatily”。
出现该状态代码时，浏览器能够⾃动访问新的URL，因此它是⼀个很有⽤的状态代码。
严格地说，我们只能假定只有当原来的请求是GET时浏览器才会⾃动重定向。
服务器常见错误代码500、501、502、503、504、505⼀：500错误1、500 Internal Server Error 内部服务错误：顾名思义500错误⼀般是服务器遇到意外情况，⽽⽆法完成请求。
2、500出错的可能性： a、编程语⾔语法错误，web脚本错误 b、并发⾼时，因为系统资源限制，⽽不能打开过多的⽂件3、⼀般解决思路： a、查看nginx、php的错误⽇志⽂件，从⽽看出端倪 b、如果是too many open files，修改nginx的worker_rlimit_nofile参数，使⽤ulimit查看系统打开⽂件限制，修改/etc/security/limits.conf，还是出现too many open files，那就要考虑做负载均衡，把流量分散到不同服务器上去了 c、如果是脚本的问题，则需要修复脚本错误，优化代码⼆：502、504错误 1、502 Bad Gateway错误、504 Bad Gateway timeout ⽹关超时2、502、504出现的可能性 web服务器故障、程序进程不够3、⼀般解决思路 a、使⽤nginx代理，⽽后端服务器发⽣故障；或者php-cgi进程数不够⽤；php执⾏时间长，或者是php-cgi进程死掉；已经fastCGI使⽤情况等都会导致502、504错误。
b、502 是指请求的php-fpm已经执⾏，但是由于某种原因⽽没有执⾏完毕，最终导致php-fpm进程终⽌。
⼀般来说，与php-fpm.conf的设置有关，也与php的执⾏程序性能有关，⽹站的访问量⼤，⽽php-cgi的进程数偏少。
针对这种情况的502错误，只需增加 php-cgi的进程数。
具体就是修改/usr/local/php/etc/php-fpm.conf⽂件，将其中的max_children值适当增加。
这个数据要依据你的服务器的配置进⾏设置。
⼀般⼀个php-cgi进程占20M内存，你可以⾃⼰计算下，适量增多。
上海纽斯达科技Nginx常见错误与解决方法上海纽斯达科技有限公司2014-10-25文档状态目的：在Nginx服务器出现故障时，能快速定位并解决相关错误。
保密：本文档仅供内部使用，请勿外传概述：Nginx常见错误与问题之解决方法技术指南。
安装环境：系统环境：redhat enterprise 6.5 64bit1、Nginx 常见启动错误有的时候初次安装nginx的时候会报这样的错误sbin/nginx -c conf/nginx.conf报错内容：sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory启动时如果报异常error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 这说明我们的环境还不是和启动需要小小的配置一下解决方法(直接运行)：32位系统 [root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64位系统 [root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了，在进程列表里会有最起码两个， worker(nginx工作进程)和master（nginx主进程）root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -cconf/nginx.confnginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker processroot 4356 28335 0 02:30 pts/1 00:00:00 grep nginxNGINX 就 OK了2、400 bad request错误的原因和解决办法配置nginx.conf相关设置如下.client_header_buffer_size 16k;large_client_header_buffers 4 64k;根据具体情况调整，一般适当调整值就可以。
Nginx服务器中414错误和504错误的配置解决⽅法414 Request-URI Too Large#客户端请求头缓冲区⼤⼩，如果请求头总长度⼤于⼩于128k，则使⽤此缓冲区，#请求头总长度⼤于128k时使⽤large_client_header_buffers设置的缓存区client_header_buffer_size 128k;#large_client_header_buffers 指令参数4为个数，128k为⼤⼩，默认是8k。
申请4个128k。
large_client_header_buffers 4 128k;当http 的URI太长或者request header过⼤时会报414 Request URI too large或400 bad request错误。
可能原因场景1.cookie中写⼊的值太⼤造成的，因为header中的其他参数的size⼀般⽐较固定，只有cookie可能被写⼊较⼤的数据场景2.请求参数太长，⽐如发布⼀个⽂章正⽂，⽤urlencode后，使⽤get⽅式传到后台。
GET / HTTP/1.1Host: Connection: keep-aliveCache-Control: max-age=0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.31Accept-Encoding: gzip,deflate,sdchAccept-Language: zh-CN,zh;q=0.8Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3Cookie: bdshare_firstime=1363517175366;If-Modified-Since: Mon, 13 May 2013 13:40:02 GMT当请求头过⼤时，超过large_client_header_buffer时，nginx可能返回"Request URI too large" (414)或者"Bad-request"(400)错误,当Request line的长度⼤于large_client_header_buffer的⼀个buffer(128k)时，nginx会返回"Request URI too large" (414)错误，对应上⾯的场景2。
413 request entity too large 解決方法-回复413 request entity too large错误通常表示客户端发送的请求实体过大，超过了服务器的限制。
这个错误一般出现在使用HTTP协议传输数据的情况下，比如在上传文件或提交表单时。
要解决这个问题，有几个步骤可以尝试：第一步：检查服务器配置首先，检查服务器的配置文件，比如Apache的配置文件httpd.conf或Nginx的配置文件nginx.conf。
在这些配置文件中，需要找到并修改以下设置：1. client_max_body_size：这是限制客户端上传的请求实体大小的指令。
默认情况下，该值通常设置为1MB，也就是1兆字节。
可以尝试将它增加到更大的值，比如10MB或更多。
修改完成后，保存并重新启动服务器。
第二步：重新启动服务器修改配置文件后，需要重新启动Apache或Nginx服务器，使新的配置生效。
可以使用以下命令执行服务器重启操作：1. Apache：在终端中输入“sudo service apache2 restart”（Linux）或“sudo /etc/init.d/apache2 restart”（Mac）。
2. Nginx：在终端中输入“sudo service nginx restart”（Linux）或“sudo /etc/init.d/nginx restart”（Mac）。
第三步：检查上传文件大小限制如果你的错误是在上传文件时出现的，还需要检查上传文件大小的限制。
在PHP应用中，可以通过修改php.ini文件来配置上传文件大小的限制。
1. 找到php.ini文件：在终端中执行“php ini”命令，它将显示php.ini 文件的位置。
2. 修改upload_max_filesize和post_max_size：在php.ini文件中找到这两个指令，它们分别限制了上传文件和POST请求的大小。
"4"开头http状态码大全,要求就属你最多文章：云客网前面呀粗略讨论过4开头的http状态码，但是那个时候主要是为了吐槽一下“4”开头http状态码的“多事”。
简单来说就是吐槽一下“4开头的状态码都不是什么好事”这件事，这里的“好事”主要是指4开头的代表的都是错误禁止等等一般不令人愉快的消息，可不是让人不得不吐槽嘛。
400，Bad Request客户端请求的语法错误，服务器无法理解401Unauthorized请求要求用户的身份认证402Payment Required保留，将来使用404Not Found服务器无法根据客户端的请求找到资源（网页）。
通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面405Method Not Allowed客户端请求中的方法被禁止406Not Acceptable服务器无法根据客户端请求的内容特性完成请求407Proxy Authentication Required请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授408Request Time-out服务器等待客户端发送的请求时间过长，超时409Conflict服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突410Gone客户端请求的资源已经不存在。
410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置411Length Required服务器无法处理客户端发送的不带Content-Length 的请求信息412Precondition Failed客户端请求信息的先决条件错误403Forbidden服务器理解请求客户端的请求，但是拒绝执行此请求413Request Entity Too Large由于请求的实体过大，服务器无法处理，因此拒绝请求。
为防止客户端的连续请求，服务器可能会关闭连接。
Http请求返回状态码⼀、Http请求返回状态码1、2XX——成功请求返回信息为2开头的状态码时，所代表的意思是：状态码描述200 OK 请求成功201 Created 请求被创建完成，同时新的资源被创建202 Accepted 服务器已接受请求，但尚未处理203 No-Authoritative Information服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，⽽是来⾃本地或者第三⽅的拷贝。
204 No Content 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。
响应可能通过实体头部的形式，返回新的或更新后的元信息。
205 Reset Content 服务器成功处理了请求，且没有返回任何内容。
206 Partial Content 服务器已经成功处理了部分 GET 请求。
207 Multi-Status 由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是⼀个XML消息，并且可能依照之前⼦请求数量的不同，包含⼀系列独⽴的响应代码。
2、3XX——重定向请求返回信息为3开头的状态码时，所代表的意思是：状态码描述300 Multiple Choices 被请求的资源有⼀系列可供选择的回馈信息，每个都有⾃⼰特定的地址和浏览器驱动的商议信息。
301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引⽤都应该使⽤本响应返回的若⼲个 URI 之⼀。
302 Move Temporarily 请求的资源临时从不同的 URI响应请求。
303 See Other 对应当前请求的响应可以在另⼀个 URL 上被找到，⽽且客户端应当采⽤ GET 的⽅式访问那个资源。
304 Not Modified 如果客户端发送了⼀个带条件的 GET 请求且该请求已被允许，⽽⽂档的内容（⾃上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。
PHP⽂件上传限制问题PHP ⼤⽂件上传占⽤⼤量资源，因此需要对上传的⼤⼩进⾏限制，以下为相关的三个参数：client_max_body_sizeupload_max_filesizepost_max_size与以上相对应的三个报错信息：Warning: POST Content-Length of 9663102 bytes exceeds the limit of 8388608 bytes in Unknown on line 0$_FILES['file']['error']==1nginx错误：413 Request Entiry Too Largeclient_max_body_size ⽤于设置客户端 Request body（请求体）的⼤⼩上限，要上传的⽂件就在 body 体中，所以此参数可以间接的看做是对⽂件上传⼤⼩的限制。
nginx 服务器通过请求头的 Content-Length 确定 body 体的⼤⼩。
超过设置的上限会返回错误码 413 Request Entity Too Large，将此参数设置为 0 可以取消对长度的限制。
Syntax: client_max_body_size size;Default:client_max_body_size 1m;Context: http, server, locationclient_max_body_size 可以设置在 http、server、location 块中，所以我们可以对域名甚⾄⼀个请求地址来提⾼上传包的⼤⼩值。
php错误：Warning: POST Content-Length of 9663102 bytes exceeds the limit of 8388608 bytes in Unknown on line 0此时为上传⽂件⼤⼩⼤于 post_max_size 。
php ⽆警告但是获取不到上传的⽂件此时 $_FILES['file']['error']==1 ，错误原因是上传⽂件的⼤⼩⼩于 post_max_size 但是⼤于 upload_max_filesize 。
【Nginx优点】1，ip黑白名单。
2，频率限制(主要针对url)。
3，代理后端负载均衡+权值控制，定制向端集群转发规则更加灵活。
4，nginx配置文件更简洁，特别是在“超时控制“和“虚拟主机：xxx域名，appwk域名，wk域名”配置上比lighttpd简洁。
5，支持配置文件reload，减少重启等带来的用户体验。
6，对后端进行健康检查并会将状态码打在日志中，可以清晰得到后端宕机nginx 的retry是否成功，日志中打印：“retryN_status: 后端返回状态码”。
7，支持rewrite_log on可以清晰的得到rewrite匹配哪一个正则。
这个在线下迁移rewrite规则时发挥了很大作用。
由于日志打的太丰富会影响线上机器性能，线上已经关闭。
【Nginx在xxx的作用】1，前端统一分流2，防攻击3，代理后端切流量更灵活。
二，nginx配置中各个作用域nginx.conf主要且常用的四个作用域http，server，location，if。
……http {…..include mime.types;client_max_body_size 25600k;client_body_buffer_size 25600k;fastcgi_buffer_size 25600k;fastcgi_buffers 4 25600k;fastcgi_busy_buffers_size 51200k;fastcgi_temp_file_write_size 51200k;#后端负载均衡配置#include upstream.confupstream server_xxx_backends {server10.26.101.142:8080 max_fails=2 fail_timeout=1s;server10.26.101.143:8080 max_fails=2 fail_timeout=10s;…...}#pc虚拟机配置#include conf/vhost/server {listen 8080;server_name ;if ($request_uri ~ "xxx") {rewrite "xxx" "yyy" break;}location ~ "^/taskui/" {proxy_pass http://server_xxx_backends;}location ~ "^/static/" {root '/root/nginx/webroot';index index.php}location ~ / {access_log logs/access_log;fastcgi_pass 127.0.0.1:6666if ($request_uri ~ "xxx") {rewrite "xxx" "yyy" break;}}…..}#wap虚拟机配置#include conf/vhost/server {listen 8080;server_name ;…..}…...}三，问题定位与解决方案1，nginx超时、缓冲配置∙fastcgi_buffer_size 64k; #这里可以设置为fastcgi_buffers指令指定的缓冲区大小∙fastcgi_buffers 4 64k; #指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答∙fastcgi_busy_buffers_size 128k; #建议为fastcgi_buffers的两倍∙fastcgi_temp_file_write_size 128k; #在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍，设置上述数值设置太小时若负载上来时可能报502 BadGateway【问题】文库上传大附件，buffer不够用导致频繁的IO。
nginx响应超时upstreamtimedout（110：Connectiontimed。
问题描述后台server服务响应时间正常，但是请求没有打到服务器，在nginx很慢才看到error⽇志，如下：解决⽅法添加或修改nginx反向代理超时时间，如下：server {listen 80;server_name ;large_client_header_buffers 4 16k; # 读取⼤型客户端请求头的缓冲区的最⼤数量和⼤⼩client_max_body_size 300m; #设置nginx能处理的最⼤请求主体⼤⼩。
client_body_buffer_size 128k; #请求主体的缓冲区⼤⼩。
proxy_connect_timeout 600;proxy_read_timeout 600;proxy_send_timeout 600;proxy_buffer_size 64k;proxy_buffers 4 32k;proxy_busy_buffers_size 64k;proxy_temp_file_write_size 64k;……location / {uwsgi_send_timeout 600; # 指定向uWSGI传送请求的超时时间，完成握⼿后向uWSGI传送请求的超时时间。
uwsgi_connect_timeout 600; # 指定连接到后端uWSGI的超时时间。
uwsgi_read_timeout 600; # 指定接收uWSGI应答的超时时间，完成握⼿后接收uWSGI应答的超时时间。
……}提⾼nginx⽹络吞吐量buffers优化指令说明large_client_header_buffers此指令规定了⽤于读取⼤型客户端请求头的缓冲区的最⼤数量和⼤⼩。
这些缓冲区仅在缺省缓冲区不⾜时按需分配。
当处理请求或连接转换到保持活动状态时，释放缓冲区。
client_max_body_size此指令设置NGINX能处理的最⼤请求主体⼤⼩。
纽斯达科技Nginx常见错误与解决方法纽斯达科技2014-10-25文档状态目的：在Nginx服务器出现故障时，能快速定位并解决相关错误。
：本文档仅供部使用，请勿外传概述：Nginx常见错误与问题之解决方法技术指南。
安装环境：系统环境：redhat enterprise 6.5 64bit1、Nginx 常见启动错误有的时候初次安装nginx的时候会报这样的错误sbin/nginx -c conf/nginx.conf报错容：sbin/nginx: error while loading shared libraries: libpcre.so.1:cannot open shared object file: No such file or directory启动时如果报异常error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory 这说明我们的环境还不是和启动需要小小的配置一下解决方法(直接运行)：32位系统 [rootsever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64位系统 [rootsever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了，在进程列表里会有最起码两个， worker(nginx工作进程)和master（nginx主进程）root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -cconf/nginx.confnginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker processroot 4356 28335 0 02:30 pts/1 00:00:00 grep nginxNGINX 就 OK了2、400 bad request错误的原因和解决办法配置nginx.conf相关设置如下.client_header_buffer_size 16k;large_client_header_buffers 4 64k;根据具体情况调整，一般适当调整值就可以。
Nginx常见错误及处理⽅法404 bad request⼀般原因:请求的Header过⼤解决⽅法：配置nginx.conf相关设置1. client_header_buffer_size 16k;2. large_client_header_buffers 4 64k;413 Request Entity Too Large⼀般原因:⼀般出现在上传⽂件解决⽅法：配置nginx.conf相关设置1. client_max_body_size 10m;配置php.ini如下(必须和nginx.conf配置⼀致)1. post_max_size=10M2. upload_max_filesize=2M499 Client Closed Request⼀般原因:客户端在为等到服务器相应返回前就关闭了客户端描述符。
⼀般出现在客户端设置超时后，主动关闭socket.解决⽅法：根据实际Nginx后端服务器的处理时间修改客户端超时时间。
500 Internal Server Rrror⼀般原因：脚本错误，（php语法错误、lua语法错误）访问量过⼤，系统资源限制，不能打开过多⽂件磁盘空间不⾜。
（access log开启可能导致磁盘满溢关闭）解决⽅法：语法错误查看nginx_err_log php_err_log。
⽂件访问量：1.修改nginx配置⽂件1. worker_rlimit_nofile 65535;2.修改/etc/security/limits.conf1. * soft nofile 655352. * hard nofile 65535502 Bad Gateway、503 Serveice Unavailable⼀般原因:后端服务⽆法处理，业务中断。
解决⽅法：从后端⽇志获取错误原因，解决后端服务器问题。
504 Gateway Timeout⼀般原因:后端服务器在超时时间内，未响应Nginx代理请求解决⽅法：根据后端服务器实际处理情况，调正后端请求超时时间。
413RequestEntityTooLarge问题及⽅案详细分析发现问题由于这是前⼈写的代码，出现问题时没有太多实现逻辑和记忆可参考。
测试环境在某些时候接⼝会报错413 Request Entity Too Large, 初步观察是由于 Cookie 带有重复的授权信息导致。
导致问题的原因同⼀个 host 的不同端⼝下有不同的应⽤创建不同的 Cookie, 当某个 API 发起请求时，会带上所有应⽤的 Cookie，导致 Cookie 长度过⼤。
进⼊⼀同个 IP 下的某端⼝登录应⽤，这时候会向浏览器写⼊ Cookie。
随着不同端⼝的应⽤越来越多，存储的 Cookie 越来越多。
当某个 API 发起请求时，会带上所有应⽤的 Cookie，导致 Cookie 长度过⼤。
达到⼀定程序时，就会触发 http 服务的 header 长度限制，导致请求失败。
浏览器演⽰postman 演⽰为什么开发环境没有发现此问题不同的⼈开发不同的项⽬，不会造成多个项⽬的 Cookie 累加的情况有 localhost/127.0.0.1/192.x.x.x 可以访问同⼀个项⽬当正常退出时 Cookie 会被清除疑问Cookie 是前端写的后端写的为什么会有这个疑问？因为都知道前后端都可以写 Cookie，并且后端可以决定是否携带 Cookie。
那么如果假设这个 Cookie 就是后端写的，那这个问题就应该由后端去解决。
从接⼝ Response 信息以及前端代码 Cookies.set 相关代码基本可以确定 Cookie 是前端写⼊的。
是否后端要求的就是当前所需的实现呢(携带其他端⼝下的 Cookie)如果是，那么这个问题也应该由后端去解决。
根据经验，我们先假设不是。
假设依据：存在有 Authorization/Blade-Auth 类似授权字段不包含其他端⼝ Cookie 时系统也可正常使⽤携带其他端⼝的 Cookie 是规范规定的，Cookie 不提供端⼝隔离同时存在多个类似授权的 header查看 API 的请求报⽂，可以发现以下 3 个类似授权的 header：Authorization: xxxBlade-Auth: xxxCookie: xxx那么问题来了，这三个字段有什么不同？到底哪个是⽤于授权的？由于存在 Authorization/Blade-Auth 字段，先假设 Cookie 是没有⽤的，或者 Cookie 只是⽤于暂存授权信息。
413 request entity too large 解決方法摘要：1.问题概述：413 Request Entity Too Large2.原因分析：服务器拒绝请求的原因3.解决方法：减小请求实体大小4.具体实施步骤：调整请求头和内容长度5.额外建议：优化代码和网络传输正文：在使用网络请求时，有时会遇到413 Request Entity Too Large的错误，这意味着服务器拒绝了我们的请求。
本文将介绍该问题的原因及解决方法。
原因分析：413 Request Entity T oo Large错误通常是由于请求实体过大，超过了服务器允许的范围。
这种情况可能是由于以下几个原因导致的：1.请求头中的内容类型或编码错误：确保请求头中的内容类型和编码设置正确，以免服务器无法正确处理请求。
2.请求内容过大：检查请求体中的数据是否过于庞大，比如上传的文件过大或传递的JSON数据过长。
3.服务器配置问题：服务器限制了允许的请求实体大小，可以通过调整服务器配置或联系空间提供商增加允许的请求实体大小。
解决方法：要解决413 Request Entity Too Large问题，我们需要减小请求实体的大小。
以下是一些建议：1.调整请求头：确保请求头中的内容类型和编码设置正确。
例如，对于JSON数据，可以使用以下请求头：```Content-Type: application/jsonContent-Length: 123```2.减小请求内容长度：检查请求体中的数据，尽量避免传递过大的数据。
如果需要上传文件，可以考虑使用分片上传或分批提交的方式，将大文件分割成小文件逐个上传。
3.优化代码：检查代码逻辑，确保在请求数据时没有不必要的数据传递。
例如，可以考虑使用懒加载的方式，只在需要时才请求数据。
4.优化网络传输：在使用HTTP请求时，可以考虑使用HTTP/2协议，提高数据传输的效率。
同时，可以使用CDN加速，减少请求的延迟和丢包率。
Nginx报403forbidden错误（13：Permissiondenied）的解决办法查看/var/log/nginx/error.log⽇志显⽰：xxx 403 forbidden (13: Permission denied)错误。
我勒个去~引起nginx 403 forbidden通常是三种情况：⼀是缺少索引⽂件，⼆是权限问题，三是SELinux状态。
⼀、缺少index.html或者index.PHP⽂件，就是配置⽂件中index index.html index.htm这⾏中的指定的⽂件server {listen 80;server_name localhost;index index.php index.html;root / var/www;}如果在/ var/www下⾯没有index.php,index.html的时候，直接访问域名，找不到⽂件，会报403 forbidden。
⼆、权限问题，如果nginx没有web⽬录的操作权限，也会出现403错误。
解决办法：修改web⽬录的读写权限，或者是把nginx的启动⽤户改成⽬录的所属⽤户，重启Nginx即可解决chmod -R 755 / var/www三、SELinux设置为开启状态（enabled）的原因⾸先查看本机SELinux的开启状态，如果SELinux status参数为enabled即为开启状态/usr/sbin/ sestatus -v或者使⽤getenforce命令检查找到原因了，如何关闭 SELinux 呢1、临时关闭（不⽤重启）setenforce 02、修改配置⽂件 /etc/ selinux/config，将SELINUX=enforcing改为SELINUX=disabledvi /etc/ selinux/config注意：修改配置⽂件需要重启系统 reboot**********若以上⽅法都不能解决，那还需要注意⼀个地⽅*********查看nginx.conf:user nobody改成：user root停⽌nginx -s stop重启nginx -c nginx.conf以上所述是⼩编给⼤家介绍的Nginx报403 forbidden错误 (13: Permission denied)的解决办法，希望对⼤家有所帮助，如果⼤家有任何疑问请给我留⾔，⼩编会及时回复⼤家的。
Nginx常见错误与解决方法目的：在Nginx服务器出现故障时，能快速定位并解决相关错误。
保密：本文档仅供内部使用，请勿外传概述：Nginx常见错误与问题之解决方法技术指南。
安装环境：系统环境：redhat enterprise 6.5 64bit1、Nginx 常见启动错误有的时候初次安装nginx的时候会报这样的错误sbin/nginx -c conf/nginx.conf报错内容：sbin/nginx: error while loading shared libraries: libpcre.so.1:cannot open shared object file: No such file or directory启动时如果报异常error while loading shared libraries: libpcre.so.1: cannot openshared object file: No such file or directory 这说明我们的环境还不是和启动需要小小的配置一下解决方法(直接运行)：32位系统[root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64位系统[root@sever lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64然后执行ps -ef | grep nginx 查看nginx进程确认是否真的已经启动了，在进程列表里会有最起码两个，worker(nginx工作进程)和master（nginx主进程）root 4349 1 0 02:24 ? 00:00:00 nginx: master process sbin/nginx -cconf/nginx.confnginx 4350 4349 0 02:24 ? 00:00:00 nginx: worker process root 4356 28335 0 02:30 pts/1 00:00:00 grep nginxNGINX 就 OK了2、400 bad request错误的原因和解决办法配置nginx.conf相关设置如下.client_header_buffer_size 16k;large_client_header_buffers 4 64k;根据具体情况调整，一般适当调整值就可以。
解决nginx配置不当导致接⼝请求数据被截断的问题问题最近请求⼀些接⼝，发现浏览器端拿到的JSON返回数据被截断，前端⽆法解析。
分析Java后端没有报错，⼀般就是反向代理的问题，Nginx配置有很⼤的嫌疑。
1. 检查nginx的error_log，发现确实nginx报错：2020/07/28 14:13:49 [crit] 113301#0: *45739 open() "/opt/work/nginx/proxy_temp/6/10/0000000106" failed (13: Permission denied) while reading upstream, client: x.x.x.y, server: x.x.x.x, request: "GET /api/some/address?startTime=159********查看⽬录权限发现：/opt/work/nginxdrwxrwxr-x 11 hue hue 4.0K Oct 31 2019 .drwxrwxr-x 15 hue hue 4.0K Aug 2 2019 ..drwx------ 2 nobody hue 4.0K Mar 21 2019 client_body_tempdrwxrwxr-x 2 hue hue 4.0K Jun 17 09:56 confdrwx------ 2 nobody hue 4.0K Feb 19 2019 fastcgi_tempdrwxr-xr-x 2 hue hue 4.0K Feb 19 2019 htmldrwxrwxr-x 2 hue hue 4.0K Feb 19 2019 logs-rw-r--r-- 1 hue hue 6 Feb 19 2019 nginx.piddrwx------ 12 nobody hue 4.0K Feb 20 2019 proxy_tempdrwxrwxr-x 2 hue hue 4.0K Feb 19 2019 sbindrwx------ 2 nobody hue 4.0K Feb 19 2019 scgi_tempdrwx------ 2 nobody hue 4.0K Feb 19 2019 uwsgi_tempproxy_temp⽬录的owner是 nobody，启动进程的⽤户为hue。
