一 总汇
① 需求背景引出
② 官方介绍
proxy_intercept_errors on|off; 作用：当上游响应的响应码'大于等于'300[常见"404"、"500"等]时,应将响应'直接返回'客户端还是nginx捕获后"自定义"错误页面'按error_page指令'处理 思考：如果开启'on',但是没有配置'error_page'呢?会出现什么现象?
③ 案例讲解
1）实验环境
1. nginx作为'代理'服务器 -->172.25.2.100 2. 上游服务器也是'nginx'["为了简单"] -->172.25.2.157 备注：也可以为'python、tomcat、php、perl'等应用程序均可 补充：更简单的是一个主机上'启'两个nginx,'端口'不一样
2）代理服务器配置
3）上游[后端服务器]配置
4）测试1
1. 上面的是'nginx代理'的日志 2. 下面的是'上游服务器'的日志
5）测试2
6）测试3
（1）后端服务器直接断开,nginx代理侧的日志
说明1：显然请求没有到达'后端服务',但是'nginx'还是记录'upstream_status为502',所以这个值'不能'表明建立了'tcp'连接 说明2：status和'upstream_status'不一定总是'一致的'
（2）思考
++++++++++ "思考一个问题" ++++++++++ 如果'代理侧'开启拦截共功能'on',但是'error_page'没有配置'补获'对应的'错误码',那客户端得到的'报错信息'是谁提供的? --> '后端的'
1. 上面是nginx'代理'配置 -->没有配置'502',配置了'500、503、504'、同时'开启拦截' 2. 下面是'后端服务器'配置
++++++++++++"测试"++++++++++++
（3）对比实验
1. 上面是'nginx'代理侧的日志 2. 下面是'后端服务器'的日志
参考链接
nginx模拟死循环
nginx的internal指令
遗留1： nginx的高级正则应用 -->命名补获之类
遗留2：探究location @的应用场景
遗留3：error_page也可以对客户端的请求进行直接返回错误页面
