什么是502 bad gateway nginx

来源：小高教学网作者：本站时间：2023-05-09 22:43:01 阅读次数：0

近期不少网友都在问：什么是502 bad gateway nginx，小编也是查阅很多资料，整理了一些相关方面的答案，大家可以参考一下。

【温馨提示】本文共有14713个字，预计阅读完需要37分钟，请仔细阅读哦！

目录：

1、晓桂科技，Nginx的502和504报错的解决方法
2、AWS EBS 中 HTTP 502错误网关的故障排除
3、上网时遇到的 404 是什么意思？
4、详解Nginx的rewrite应用
5、DNSSEC协议缘何在企业部署进展缓慢?

晓桂科技，Nginx的502和504报错的解决方法

一、错误提示说明：

nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行，但是由于某种原因（壹般是读取资源的问题）没有执行完毕而导致PHP-CGI进程终止。

Nginx 504 Gateway Time-out的含义是所请求的网关没有请求到，简单来说就是没有请求到可以执行的PHP-CGI。

二、错误提示原因分析：

解决这两个问题其实需要综合思考的，一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关，

而Nginx 504 Gateway Time-out则是与Nginx.conf的设置有关。

php-fpm.conf有两个至关重要的参数，一个是”max_children”,另一个是”request_terminate_timeout” ，但是这个值不是通用的，而是需要自己计算的。

计算的方式如下：

如果你的服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点，也就是说你的PHP-CGI可能出现某个BUG，或者你的宽带不够充足或者其他的原因导致你的PHP-CGI能够假死，那么就建议你给”request_terminate_timeout”赋一个值，这个值可以根据你服务器的性能进行设定。壹般来说性能越好你可以设置越高，20分钟 -30分钟都可以。由于服务器PHP脚本需要长时间运行，有的可能会超过10分钟因此我设置了900秒，这样不会导致PHP-CGI死掉而出现502 Bad gateway这个错误。

而”max_children”这个值又是怎么计算出来的呢？这个值原则上是越大越好，php-cgi的进程多了就会处理的很快，排队的请求就会很少。设置”max_children”也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M 左右，因此我的”max_children”我设置成40个，20M*40=800M也就是说在峰值的时候所有PHP-CGI所耗内存在800M以内，低于有效内存1Gb。而如果我的”max_children”设置的较小，比如5-10个，那么php-cgi就会“很累”，处理速度也很慢，等待的时间也较长。如果长时间没有得到处理的请求就会出现504 Gateway Time-out这个错误，而正在处理的很累的那几个php-cgi如果遇到了问题就会出现502 Bad gateway这个错误。

三、临时解决办法如下：

Nginx提示502和504错误的临时解决办法是：

1、调整php-fpm.conf的相关设置：

30s

2、调整nginx.conf的相关设置：

server_tokens off;

sendfile on;

tcp_nopush on;

server_names_hash_bucket_size 256;

client_header_buffer_size 256k;

large_client_header_buffers 4 256k;

client_body_buffer_size 256k;

client_header_timeout 3m;

client_body_timeout 3m;

send_timeout 3m;

client_max_body_size 50m;

keepalive_timeout 120;

#fastcgi_connect_timeout 300;

#fastcgi_send_timeout 300;

#fastcgi_read_timeout 300;

#fastcgi_buffer_size 64k;

#fastcgi_buffers 4 64k;

#fastcgi_busy_buffers_size 128k;

#fastcgi_temp_file_write_size 128k;

fastcgi_intercept_errors on;

fastcgi_connect_timeout 600;

fastcgi_send_timeout 600;

fastcgi_read_timeout 600;

fastcgi_buffer_size 256k;

fastcgi_buffers 16 256k;

fastcgi_busy_buffers_size 512k;

fastcgi_temp_file_write_size 512k;

四、解决方案如下：

A、crontab里写入php-fpm的平滑重启命令

B、适当提高children的数值，降低max_requests的数值。

建议壹般云主机的children在5-10，max_requests在1000-2000，具体自行调整。

降低max_requests的数值可使php-cgi重启的周期缩短，

偶然的高内存操作造成的问题影响时间也会缩短。

AWS EBS 中 HTTP 502错误网关的故障排除

了解如何在 AWS EBS 中故障诊断 HTTP502错误网关

我们将在本文中讨论的应用程序是在 Amazon Web Services (AWS)中的 Elastic Bean}(EBS)服务上运行的。这个应用程序间歇性地抛出 HTTP502Bad 网关错误。在这篇文章中，让我们讨论如何在 Elastic Bean}服务中排除和解决这个 HTTP 502错误网关错误。

AWS Elastic Beanstalk ArchitectureAWS Elastic Beanstalk结构

这个应用程序在 AWS Elastic BeanStalk 服务(EBS)中的 AWS Elastic Load Balancer、 Nginx 1.18.0、 Java 8、 Tomcat 8和 Amazon Linux 上运行。对于那些不太熟悉 EBS 的人来说，下面是它的高级体系结构。

图: AWS Elastic Beanstalk

有一个自动气象站弹性负载平衡器的前沿。这个负载均衡器将把流量分配给一组 EC2实例(可以自动缩放)。每个 EC2实例将有一个 Nginx Web 服务器和一个 Tomcat 应用程序服务器。弹性负载均衡器发送的请求首先由 Nginx 服务器处理。然后 Nginx 服务器将请求转发到 tomcat 服务器。

HTTP 502 Bad Gateway Error

这个应用程序间歇性地(并非总是)抛出 HTTP502错误网关错误。几秒钟后，服务将再次恢复，事情将开始正常运作。目前还不清楚是什么原因导致了 AWS Elastic Bean}环境中的 HTTP502错误网关。

我们首先需要理解这个 HTTP502错误网关错误意味着什么。当 Web 服务器/网关/代理服务器从与之交谈的后端服务器获得无效响应时，将抛出此错误。

HTTP 502 Thrown by Nginx in AWS EBS

现在的问题是: EBS 堆栈中有三个主要组件:

弹性负载平衡器
网络服务器
应用服务器

在这3个组件中哪一个是抛出 HTTP502坏网关错误？

图: Nginx 服务器抛出的 HTTP 502错误网关错误的截图

上面是我们接收到的 HTTP502坏网关错误的截图。在这个屏幕截图中有一个线索来指示是谁抛出了这个 HTTP502错误。如果您注意到屏幕上突出显示的部分，您将看到 Nginx 服务器抛出这个 HTTP502坏网关错误。

根据 HTTP 502错误定义，Nginx 只有在从 tomcat 服务器得到无效响应时才会抛出此错误。因此，这条线索有助于缩小 Tomcat 服务器是问题根源的范围。

Out of Memory: Kill Process or Sacrifice Child

为了确定问题的根源，我们在运行 tomcat 服务器的 EC2实例上执行了开源的 yCrash 脚本。YCrash 脚本从技术堆栈中捕获了16个不同的工件，其中包括: 垃圾收集日志、线程转储、堆转储、 ps、 top、 top-H、 vmstat、 netstat，... ..。我们将捕获的构件上传到 yCrash 服务器进行分析。

YCrash 脚本捕获的构件之一是内核日志文件。在这个日志文件中，可以找到 Linux 内核中发生的所有事件。YCrash 从日志文件中提取出关键错误和警告并显示它们。下面是 yCrash 生成的内核日志的分析报告。

图: yCrash 的内核日志分析报告“内存不足: 终止进程或牺牲子进程”

请参阅内核日志中突出显示的错误消息:

[Sat May 21 17:31:00 2022] Out of memory: Kill process 24339 (java) score 874 or sacrifice child

它表示作为 Java 进程的 Tomcat 服务器已经终止。如果进程的内存消耗超过了设备的 RAM 容量限制，Linux 内核将终止进程。这也是在这个应用程序中发生的确切场景。只要应用程序的内存消耗超过容量限制，Linux 内核就会终止 tomcat 服务器。

根本原因-内存不足

现在的问题是: Linux 如何终止可能导致间歇性 HTTP 502错误网关错误的 tomcat 服务器？难道不应该完全停机吗？这是个合理的问题。

如果您还记得，这个应用程序正在 AWS Elastic Bean}(EBS)服务上运行。每当 tomcat 服务终止时，EBS 服务将自动重新启动 tomcat 服务器。所以很搞笑。Linux 正在终止，EBS 正在重新启动 tomcat 服务器。在这个间歇期间，客户经历 HTTP502坏网关错误。

解决方案-升级 EC2实例 RAM 容量

显然，应用程序运行在仅有1GB RAM 容量的 EC2实例上。运行 tomcat 服务器、 Nginx 服务器和其他内核进程的内存不足。因此，当应用程序升级为在2GB RAM 容量的 EC2实例上运行时，问题得到了解决。

注意: 在非 AWS 环境中运行的另一个应用程序也面临类似的问题。这可能也是一本有趣的书。

上网时遇到的 404 是什么意思？

随着网络时代的发展与进步，我们的学习工作和生活早已离不开互联网，智能家居、网上购物、日常出行都需要互联网的支持。互联网切切实实地给生活带来了诸多便利。

那大家有没有碰到过这么一个情况呢？当我们在使用手机或者电脑浏览一些信息的时候，或者在搜索引擎中搜索资料，点击搜索结果跳转后，浏览器跳出一个 404 Not Found 的空白页。

相信各位老网民都很熟悉“404”这个数字了，这个错误代码代表着服务器未找到文件，通常出访问的页面已经被更改或者移除，或是输入了错误的访问地址错误。

那为什么用 404 而不是其他的数字来代表访问资源不存在呢？互联网上对 404 的诞生有这么一个“传说”。据传在第三次科技革命前，整个互联网的形态就像是一个大型的中央数据库，并设置在一个叫 404 的房间里。那个时候，所有的互联网访问请求都由人工手动完成，若在 404 房间中没有找到请求者所需要的文件，或是由于请求者写错了文件编号，工作人员就会返回一个“Room 404 : File Not Found”的信息。

当然，经实际考证后发现传说中的 Room 404 其实并不存在，而 404 的真正

状态码的由来

众所周知，互联网的建立打破了地域限制，通过浏览器与服务器之间的交流让我们足不出户知天下。而浏览器与服务器之间的交流则是通过 HTTP 协议。

HTTP（Hypertext Transfer Protocol），超文本传输协议，它是应用层协议。由于其简捷、快速的方式，适用于分布式和合作式超媒体信息系统。自 1990 年起应用于万维网（WWW）全球信息服务系统。

用户上网的过程，就是浏览器通过 HTTP 协议向服务端发送请求，然后将服务端主机上的内容显示到本地。

支撑着 HTTP 协议工作的是 TCP/IP 协议这个模范打工人，它负责了底层的数据传输工作。单从这一点上来看，所谓的“超文本传输协议”其实和传输没什么联系，有点名不副实。那为什么 HTTP 还被称为传输协议呢？答案就是它是传输报文内容的。

HTTP 协议在规范文档里详细定义了报文的格式，规定了组成部分，解析规则，还有处理策略，所以可以在 TCP/IP 层之上实现除了数据传输外，更灵活丰富的功能。

TCP 的协议报文，在实际要传输的数据之前附加了一个 20 字节的头部数据，存储 TCP 协议必须的额外信息，例如发送方的端口号、接收方的端口号、包序号、标志位等等。有了这个附加的 TCP 头，数据包才能够正确传输，到了目的地后把头部去掉，就可以拿到真正的数据。

HTTP 协议也需要在实际传输的数据前附加这类头数据，不过与 TCP 不同的是，它是一个“纯文本”的协议，头数据都是 ASCII 码的文本，可以很容易地用肉眼阅读，不用借助程序解析也能够看懂。

HTTP 协议的请求报文和响应报文的结构基本相同，主要由三大部分组成：

状态行（status line）：描述响应的基本信息，也就是服务器响应的状态；
头部字段集合（header）：使用 key-value 形式更详细地说明报文；
消息正文（entity）：实际响应的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

其中状态行和头部字段经常又合称为“响应头”，消息正文又称为“实体”，与“header”对应，很多时候直接称为“body”。

HTTP 协议规定报文必须有 header，但可以没有 body，且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

△ 完整 HTTP 响应报文

以又拍云存储接口文件上传完毕后返回的响应报头为例，第一行“HTTP/2 200 OK”为状态行，由三部分构成：

版本号：表示报文使用的 HTTP 协议版本，上图中版本为 HTTP/2；
状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，404 是资源不存在；
原因短语：作为数字状态码补充，是状态码的简短文字描述，例如“OK”“Not Found”。

而后面的“Content-Type”、“Connection”等等都属于 header，报文的最后是一个空白行结束，没有 body。

多数情况下 HTTP 报文只有 header 没有 body。虽然 HTTP 协议对 header 的大小没有做限制，但因为头部太大可能会占用大量的服务器资源，影响运行效率。因此各个 Web 服务器都不允许过大的请求头。即便如此很多时候互联网上依然是很多大头在跑来跑去。

为了尽可能减少“大头”占用的资源，减少检测错误地址访问的时间，网站一般选择状态码来负担这个责任，因为数字比起文字能够更好地减小 HTTP 报文头部体积。

响应报文可以让客户端快速地通过状态码知道请求是否被正确处理，让服务端可以通过状态码选择最恰当的状态处理请求回复客户端。同时通过各类状态码，让服务端明确告知客户端响应状态，让客户端明确自己的下一步操作。

目前 RFC 标准里总共有 41 个状态码，并允许自行扩展。Apache、Nginx 等 Web 服务器都定义了一些专有的状态码。在开发 Web 应用的时候，我们也可以在不冲突前提下设置自己的专有状态码。

常见状态码

接下来，我们详说一下常见的各个状态码都代表着什么？

状态码的意义在于表达 HTTP 数据处理的“状态”，客户端可以依据代码实时转换处理状态，一般是一个十进制数字，而 RFC 标准里规定的状态码是三位数，取值范围从 000 到 999。常见的状态码有一定的设计格式，被分成了五类，用数字的第一位表示分类，而 0~99 不用，这样状态码的实际可用范围就大大缩小了，由 000~999 变成了 100~599。

1xx

1×× 类状态码属于提示信息，是协议处理的中间状态，实际能够用到的时候很少。

我们偶尔能够见到的是 “101 Switching Protocols”。它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改为其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。

此外还有 “100 Continue” 。表示目前为止一切正常, 客户端应该继续请求, 如果已完成请求则忽略。一般出现在文件上传中。

2xx

2×× 类状态码表示服务器收到并成功处理了客户端的请求，这也是客户端最愿意看到的状态码。

“200 OK”是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果。

“204 No Content”是另一个很常见的成功状态码，它的含义与“200 OK”基本相同，但响应头后没有 body 数据。

“206 Partial Content” 一般用于分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。状态码 206 通常还会伴随着头字段“Content-Range”，表示响应报文里 body 数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-66/888”，意思是此次获取的是总计 888 个字节的前 66 个字节。

3xx

3×× 类状态码表示客户端请求的资源发生了变动，客户端必须用新的 URI 重新发送请求获取资源，也就是通常所说的“重定向”，包括“著名”的 301、302 跳转。

“301 Moved Permanently”俗称“永久重定向”，含义是此次请求的资源已经不存在了，需要改用新的 URI 再次访问。与它类似的是“302 Found”，曾经的描述短语是“Moved Temporarily”，俗称“临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。

“304 Not Modified” 是一个比较有意思的状态码，它用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。

4xx

4××类状态码表示客户端发送的请求报文有误，服务器无法处理，它是具有真正的“错误码”含义的状态码了。

“400 Bad Request”是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头或者还是其他错误则不会明确指示，因此在 Web 开发时一般会尽量避免给客户端返回 400，使用其他更有明确含义的状态码。

“403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等。

“404 Not Found”可能是我们最常看到的一个状态码，它一般指资源在本服务器上未找到，所以无法提供给客户端。

4×× 里剩下的一些代码较明确地说明了错误的原因，都很好理解，开发中常用的有：

405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
408 Request Timeout：请求超时，服务器等待了过长的时间；
409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
413 Request Entity Too Large：请求报文里的 body 太大；
414 Request-URI Too Long：请求行里的 URI 太大；
429 Too Many Requests：客户端发送了太多的请求，触发了服务器的限制；
431 Request Header Fields Too Large：请求头某个字段或总体太大。

5xx

5×× 类状态码表示客户端请求报文正确，但服务器在处理时内部发生了错误，无法返回应有的响应数据，是服务器端的“错误码”。

“500 Internal Server Error” 与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。不过和 400 的响应相反，开发人员通常不会把服务器内部的出错详细信息返回给访问端。虽然不利于调试，但能够防止黑客的窥探或者分析。

“501 Not Implemented” 表示客户端请求的功能还不支持，类似于“即将开业，敬请期待”的意思。

“502 Bad Gateway” 通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。

“503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。

如何处理 404

回到我们开头所说的 404 问题。在实际业务中，难免会碰到输入了错误链接地址访问到不存在的资源，或者服务器突发故障无法访问的情况。但 Web 服务器默认提供的错误响应页面，无论 Nginx、Apache 或者是 IIS，都不是十分美观，页面简陋、呆板，且对用户不友好，无法给用户提供直观明了的信息，造成用户使用体验的下降。

因此，很多开发者均使用自定义错误页面的方式，来增强户体验，避免用户流失。以 404 举例来说，自定义 404 页面通用的做法是在页面中放置网站快速导航链接、搜索框以及网站提供的特色服务，这样可以有效的帮助用户访问站点并获取需要的信息。

例如很多开发者会使用腾讯公益提供的“宝贝回家 – 公益 404 项目”，开发者可以在自定义的 404 界面中引用一段代码，当用户访问到 404 的资源，网页会显示访问资源不存在，同时加载一些失踪儿童的信息，通过互联网来迅速传播失踪儿童信息，从而提高找回失踪儿童的概率。这种操作让科技充满了温度，体现了人文关怀，正是科技的浪漫所在。

如果你不知道如何自定义错误响应页，但是又很想拥有。你可以看一下 CDN 、或者云存储服务的自定义页面功能。它可以帮助你快速的配置 4XX、5XX 的错误响应页。只需要打开控制台，就可以根据自己的需求配置错误响应也和错误响应图，非常方便好用。

除此之外，还可以通过边缘规则，让不同错误码对应不同的网址跳转、URL 改写等网页引导操作。

详解Nginx的rewrite应用

概述

Rewrite主要的功能是实现URL重写，Nginx 的 Rewrite 规则采用 PCRE Perl 兼容正则表达式的语法进行规则匹配，如相使用 Nginx 的 Rewrite 功能，在编译 Nginx 前要编译安装 PCRE 库。

Nginx使用if进行条件匹配

Nginx可以用if进行条件匹配，语法规则类似C

if （条件）{...} ( 可用于： server,location ) ## 检查一个条件是否符合，如果条件符合，则执行大括号内的语句。不支持嵌套，不支持多条件 && ||

例如：if ($http_user_agent ~ MSIE) {rewrite ^(.*)$ /msie/$1 break;}

1、正则表达式匹配，其中：

~ 为区分大小写匹配

~* 为不区分大小写匹配

!~和!~*分别为区分大小写不匹配及不区分大小写不匹配

2、文件及目录匹配，其中：

-f和!-f用来判断是否存在文件

-d和!-d用来判断是否存在目录

-e和!-e用来判断是否存在文件或目录

-x和!-x用来判断文件是否可执行

例如：if (!-f $request_filename) {proxy_pass http://127.0.0.1;}

Wordpress的重定向规则：

if (!-e $request_filename) {rewrite ^/(index|atom|rsd).xml$ http://feed.shunz.net last;rewrite ^([_0-9a-zA-Z-] )?(/wp-.*) $2 last;rewrite ^([_0-9a-zA-Z-] )?(/.*.php)$ $2 last;rewrite ^ /index.php last;}

return ( 可用于： server,location,if ) ## 用于结束规则的执行并反回状态码给客户端。状态码可以是：204/400/402~406/408/410/411/413/416/500~504

如：

location ~ .*.(sh|bash)?$ { return 403; }

## 访问的 URL 以 .sh .bash 结尾的，则返回 403 。

204 No Content

400 Bad Request

402 Payment Required

403 Forbidden

404 Not Found

405 Method Not Allowed

406 Not Acceptable

408 Request Timeout

410 Gone

411 Length Required

413 Request Entity Too Large

416 Requested Range Not Satisfiable

500 Internal Server Error

501 Not Implemented

502 Bad Gateway

503 Service Unavailable

504 Gateway Timeout

Nginx使用rewrite

rewrite ( 可用于： server,location,if ) ## 重写 URL ，或修改字符串。重写 URL 只对相对路径有效，如想对主机名，要使用 if 语句。

例1：

if ($host ~* www.(.*)) { set $host_without_www $1; rewrite ^(.*)$ http://$host_without_www$1 permanent; }

## 如果替换串以 http:// 开头，将会采用 301 或 302 跳转进行 URL 重定向。

例2：

rewrite ^/feed/$ http://feed.shunz.net last;

Nginx的Rewrite规则与Apache几乎完全一致，所不同的是最后的flag标记，Nginx的rewrite指令后支持的标记有last，break，redirect，permanent

last 相当于Apache里的[L]标记，表示完成rewrite，不再匹配后面的规则

break ( 可用于： server,location,if ) ## 本条规则匹配完成后，终止匹配，不再匹配后面的规则

如：rewrite ^/b/(.*).html /play.php?video=$1 break;

redirect 返回302临时重定向,浏览器会显示跳转后的URL地址

permanent 返回301永久重定向，浏览器会显示跳转后的URL地址

last/break用来实现URL重写，浏览器地址栏的URL不变，但在服务器端访问的路径发生了变化。

redirect/permanent实现URL跳转，浏览器地址栏URL会显示跳转后的URL。

使用 alias 指令时必须用 last 标记，使用 proxy_pass 指令时要用 break 表示。last 标记在本条 rewrite 规则执行完毕后，会对其所在 server{....}标签重新发起请求，而 break 标记则在本条规则匹配完成后，终止匹配。

如：

location /cms/ { proxy_pass http://test.abc.com; rewrite "^/cms/(.*).html$" /cms/index.html break; }

## 这条规则如果使用 last 会导致死循环。

## 一般在根 location 中（即 location / {....}）或直接在 server 标签编写 rewrite 规则，推荐使用 last 标记，

在非根 location 中 (即 location /cms/ {...}),则使用 break 标记。

Nginx $document_uri参数的使用

$document_uri 表示访问的url 现在我的需求是，访问 www.abc.com 请求到 www.abc.com/abc/

在nginx配置文件中加入

if ($document_uri !~ 'abc') { rewrite ^/(.*)$ http://www.abc.com/abc/$1 permanent; }

而不是单独加一句 rewrite ^/(.*)$ http://www.abc.com/abc/$1 permanent;

如果只加rewrite 规则，而不限定条件，那么会造成死循环。

后面小编会分享更多运维干货，感兴趣的朋友走一波关注哩~

DNSSEC协议缘何在企业部署进展缓慢?

DNS安全扩展(DNSSEC)在企业的部署进展缓慢，但专家表示，DNSSEC比现有的证书颁发机构(CA)系统更好，企业对部署这种技术的迟疑可能是因为对其目的的误解。

DNSSEC协议可帮助域名系统(DNS)数据中的数字签名来验证数据的

《The Internet for Dummies》

“主要的优点是，它可防止坏人伪造你的域名，让他们无法将自己的网站伪造成你的网站，”Levine表示，“更长远的优势是，你可以使用DNS来安全地发布各种新信息(最明显的是TLS证书)，而不是让它们由第三方签名。”

然而，大家对于这个协议心生恐惧，因为据称它会方便政府监控数据。该理论认为，由于证书会存储在DNS中，如果政府控制重要的顶级域名(TLD)，他们也将会控制用于验证这些证书的TLS加密的密钥。

Internet Society协会高级内容战略家Dan York称，这种认为DNSSEC方便政府监控的说法是一个谬论，因为这从来不是该协议的意图。

“DNSSEC只做一件事情：保护存储在DNS中信息的完整性。DNSSEC确保你从DNS获取的域名信息正是该域名运营商放在DNS的相同信息，”York说道，“它没有做到的是保护通信的保密性，它没有加密这些信息，因为这并不是它的工作目标。DNSSEC可以确保你连接到正确的IP地址，但在你的计算机和这些IP地址之前的通信仍然可能受到监控。”

York称，对于政府控制大量域名的说法也不完全正确。

“国家代码顶级域名(ccTLD)通常由政府控制，这些都是两个字母的域名，例如.ly和.nl，”York表示，“而大多数通用顶级域名(gTLD)都是由不同的注册机构控制，例如.com、.org

以及新的gTLD--.bank、.foo、.photos等，并且，这些注册机构几乎都是私营公司，其中大部分是商业公司。”

虽然很多ccTLD由政府控制，最流行的ccTLD(例如.de和.uk)并不是由德国和英国政府控制，而是由私营公司控制。York称，对于有些由政府控制的gTLD，用户应该首先检查他们是否担心在这些域名泄露信息，但监控并不是政府控制的问题。

“由于ccTLD运营商控制ccTLD的域名注册，他们当然可以更改你域名的记录，指向另一组DNS域名服务器，从而将你域名控制器交给另一个DNS运营商(这可能是他们自己)，然后又更改DNS记录指向另一个网站，”York称，“DNSSEC在这里并不重要，因为ccTLD运营商可以控制TLD中的记录。”

根据Levin表示，这种情况几乎不可能发生，因为在信任链中有人会注意到异常情况。

“是的，政府会侵入所有地方，但考虑到现在的CA系统已经非常糟糕，我们没有理由相信DNSSEC会更糟，”Levin称，“此外，DNSSEC很难在不被发现的情况下受到攻击，因为人们很认真看待DNS，并且有很多冗余。”

Levin说， DNSSEC也许并不完美，但与证书颁发机构的问题相比，DNSSEC其实更好。同时，他表示可以理解为什么DNSSEC的部署进展缓慢，因为目前没有主流Web浏览器可以接受使用DNSSEC的TLS。

“它非常复杂，而且工具很糟糕。我的服务器有大约300个DNS区，虽然我全部在本地签名，但签名都会被忽略，除非更高级的DNS区使用DS(授权签字人)记录链接到我的密钥，”Levin称，“DNSSEC有两种类别，被称为NSEC和NSEC3。如果你使用NSEC，别人很容易列举你的区，即找出你的DNS区中所有的域名，这在有时候可能不方便操作。”当使用NSEC时，有关有效域名的信息被添加到针对不存在域名请求的DNS回复中;而在NSEC3中，这些信息会被模糊处理。

Levin称，即使“使用被动DNS，别人都可以非常接近你的DNS，而你无法阻止这一点。NSEC3解决了列举问题，但它让DNSSEC变得比现在更加复杂，让更新DNS区等操作变得更加困难。”

York也承认，DNSSEC协议也有问题，包括新增的操作要求、更大的DNS数据包、缺乏保密性，并可能使系统更容易攻破。不过，York称，最后一个问题可以通过很多安全技术来应对。

“从历史上来看，DNS服务器经常看到网络管理员设置的条条框框，然后通常忽视它们，因为可能影响其运行。添加DNSSEC需要对DNS服务器进行一些额外的操作，”York称，“由于签名，DNSSEC会让DNS数据包变得更大，这可能影响网络流量，而缓解这个问题的一种方法是使用具有较小密钥的签名。”

York表示，目前互联网工程任务组的DPRIVE工作组正在开展工作以保护计算机和DNS服务器之间的连接，以确保试图监控你流量的人不会看到通过本地网络发送的数据包中的DNS查询。同时，针对DNSSEC很多常见的问题的解决方案正在开发中。

“DNSSEC协议的优点在于，它从一开始就被设计为可以不断发展，”York称，“与安全问题和安全算法一样，该协议也可以不断进化。”

502 Bad Gatewaynginx/1.4.4

DNSSEC协议可帮助域名系统(DNS)数据中的数字签名来验证数据的

《The Internet for Dummies》

Internet Society协会高级内容战略家Dan York称，这种认为DNSSEC方便政府监控的说法是一个谬论，因为这从来不是该协议的意图。

York称，对于政府控制大量域名的说法也不完全正确。

以及新的gTLD--.bank、.foo、.photos等，并且，这些注册机构几乎都是私营公司，其中大部分是商业公司。”

根据Levin表示，这种情况几乎不可能发生，因为在信任链中有人会注意到异常情况。

“DNSSEC协议的优点在于，它从一开始就被设计为可以不断发展，”York称，“与安全问题和安全算法一样，该协议也可以不断进化。”

502 Bad Gatewaynginx/1.4.4:

延伸阅读

【本文标题和链接】什么是502 bad gateway nginx http://www.hzhe123.cn//n/148665.html 页面最新缓存时间： 2024年05月16日星期四

为什么羽毛球由16根羽毛组成(为什么羽毛球的羽毛只有16根吗？)
什么是钱塘江?(什么是钱塘江大潮简介)