一 rewrite模块再探
① 知识回顾
1) 结合自己'遇到过'的案例场景2) 关注一些'易错'点、'难'点3) 本文内容很'杂',建议读者'选取感兴趣的阅读'rewrite模块
rewrite功能
② nginx中利用if 等价&&多条件
需求背景： 1) nginx'不'支持'&&、||、and、or'等逻辑操作符场景： 一个变量'多个值'的场景案例： if ($http_name ~ ^(jane|tony)$) { } <==> 任意条件'满足'即可,相当'||'2) 思考：如何'实现' 类似 if ($arg_a == "" && $arg_b == "") 形式3) 本文针对不同场景,通过'3种'方式来'实现&&'4) 不建议if'进行多条件'判断注意: 首先'测试案例'要全面,避免有'遗漏',其次测试方式多样化："浏览器和curl"多种方式5) 以下只是提供了'一种解决问题'的思路,要根据'场景'合理使用正则表达式中的if then else 正则表达式if语句
方式1： '多个条件'刚好在一个'变量'中,可以用'if 正则'进行匹配
方式2： 可以通过'map'进行变量的'组合嵌套',然后通过 if ($new_var ~)进行匹配备注： 这里演示只是'简单'进行变量判断map优点： 'text'文本可以使用'多个变量',最终'解析的字符串'作为最终的text文本;if'不行'
方式3：变量初始化,然后多个if层层判断 其它参考
原理： 首先通过'if'设置'$flag'标志位,然后在if判断过程中改变'$flag'达到效果
方式4：PCRE正则表达式if语句
方式4： PCRE正则'零宽度断言',来'模拟if'语句的行为,在匹配模式时根据'条件'选择'不同'的模式(?(condition)true-pattern|false-pattern) --> "遗留"备注1： 一般'condition'使用'?=regex、?!regex、?<=regex、?<!regex'或'?=regex'形式备注2：'condition'也可以使用其它'任何'形式应用场景： 变量之间有'依赖关系',这里的依赖指的是'值'有关联 --> '某种正则模式'、'包含'关系补充： 1) 关于正则'被匹配的地方':不能'引用已存在的变量($解读正则字符)'、但可'通过补获产生新变量'备注： 不管是'map ~',还是'if 中 ~',变量表示的'pattern'都不会进行'解析'补充： '非'正则场景,if ($http_name = ${arg_name}) {...} --> "变量解析字面字符串"2) 匹配'地方'可以预定义变量：$(http|arg|cookie)_xx --> 产生'独一无二的变量',避免报错3) 重点： nginx正则不支持'$var'变量内插,不会进行'变量解析',而是直接作为'正则字符'
④ if进行域名跳转
背景： 'A域名'要下线,在'彻底下线'过渡阶段,'A'域名跳转到'B'域名,只进行'域名替换'细节点： 在server块配置,在'location_config寻址前',直接处理
⑤ if指令再探
1) 从'源码'分析'unexpect if'案例2) 从'案例'加以'原理'辅助理解3) if指令是'邪恶'的:不了解'nginx的执行阶段,在'location内'滥用,'server context'不存在4) 目的： 如何'随心所欲'的使用if,写出'符合要求'的配置if指令是邪恶的
+++++++++ "if的一些非预期的案例场景" +++++++++"重点结论":1) 如果location上下文'if'指令的结果是'match' 的,那么 if 会创建一个'内嵌的 location 块'2) 只有这里面的 content 处理指令'NGX_HTTP_CONTENT_PHASE 阶段'会执行3) if 条件为'真(true)'时,nginx 使用这个'无名 location 作用域的配置'处理当前请求备注： 1、在解析if指令时,会把'if'当做'location'来处理;2、并且把这个'if对应的location'的type被设置成了'noname',在内部创建一个'无名'location3、所以在进行'url匹配'时并'不会查找'到此location;
1) 过滤模块是过滤'响应头response_header'和'内容content'的模块备注： 'add_header'指令就属于'filter'模块2) 它工作在'获取响应内容'之'后',向用户发送响应之'前'3) 处理过程分为'两个阶段':过滤HTTP响应的头部和主体,在这两个阶段可以分别对头部和主体进行修改nginx的filter过滤模块 nginx的11个阶段 详解nginx的11个阶段 if is evil解读
1) proxy_pass 是一个 'action directive',动作指令2) 按照定义和其它嵌套location 的实现来看,这个指令'不应该被子作用域'继承3) 但是 location 'if(true) {}' 当作子作用域的话,会被'继承'
NGINX脚本语言原理及源码分析(一)
NGINX脚本语言原理及源码分析(二)
NGINX脚本语言原理及源码分析(三)
NGINX脚本语言原理及源码分析(四)
陶辉大神的三篇变量使用脚本指令
思考： break 指令 和 rewrite 'flag' 为break的'区别'?1) break'指令'终止所有的'rewrite模块的指令',不仅仅包括'rewrite指令',还有其它'set、if等'2) rewrite 的'falg'为break也禁止执行后续的'rewrite'模块指令执行3) 不管哪种'break',都只是停止对应'(SERVER|LOCATION)_REWRITE'阶段的'rewrite'模块指令4) 然后进入nginx的'下一个'执行阶段eg: server 块中if指令中使用rewrite ... break,还是会进行'location级别'find_location⑥ 避坑if方案
+++++++++ "绝对安全[官方推荐]" +++++++++location / {if (condition) {return ...;}if (condition) {rewrite ... last;}
}++++++++++ "分割线"location / {if ($uri = '/wzj12') {proxy_pass http://127.0.0.1:11111;break; # 这里的 break 将阻止下面 if 的执行,跳过其它rewrite模块的阶段} if ($uri ~ '/wzj1') {proxy_pass http://127.0.0.1:11112;} }++++++++++ "分割线"备注： 两个条件'互斥',不用breaklocation / {if ($uri = '/wzj1') {proxy_pass http://127.0.0.1:11111;} if ($uri = '/wzj2') {proxy_pass http://127.0.0.1:11112;} }⑦ 关于预定义变量,set可以操作的
1) 只读'变量': $request_uri、$uri、$query_string这两个变量也'不能 set'修改;2) 只有$args 、$limit_rate等极少数可以'直接 set'修改强行修改只读变量会导致程序运行错误;if ($args ~ (^|.*&)databases=(.*)) {set $args $1database=$2;
}验证： 修改'$args'是否影响'proxy_paas'? --> "会影响"
⑧ return和rewrite再探
1) return 比 rewrite 效率更'高',但是'rewrite'可以利用'正则'完成更复杂功能补充： 'rewrite'会隐式的带查询参数,可以通过'?'进行调整;但是'return'必须显示指定$args2) 重点: 只探究'相对'路径时,哪些因素影响重定向'Location'形式?思考方向：'$scheme、$host、$port、$args'涉及手段：'return code'、'rewrite ... ...["不涉及协议"] permanent|redirect'强调：建议显示指定'全路经'的重定向3) 补充： 暂时'不考虑'以下场景[1]、proxy模块涉及'proxy_redirect',以及后端'30(1|2|7|8)',及自定义Location响应头[2]、'目录资源'导致301重定向: 默认'目录资源'nginx'301'重定向;'try_files $uri/'导致
前期铺垫：nginx与Location响应头细节探讨
port_in_redirect off的两个应用场景 nginx 的port_in_redirect 问题解决
1) Location'响应头'常见的组成: [1]、$scheme://$host:$port$request_uri --> "全路径",最'常见'的形式[2]、$request_uri --> "带查询参数,相对路径"[3]、$uri --> "纯uri"备注1： 实际可以加上'#'锚点数据,但是一般'不指定,最终返回的Location响应头是相对的还是绝对'备注2： '$status'和'Location'共同作用'重定向'2) absolute_redirect['总开关'] on 备注： relative url没有'协议'、'主机名'、'端口号'3) server_name_in_redirect['host来源'] off需求：可以为被代理服务器发出的'相对重定'向增加'主机名'存在的'问题'1： 原始是通过'ip正向代理访问'的,可能'域名'无法解析、防火墙'不通'存在的'问题'2： 获取的'$server_name'是一个带正则的'字符串',客户端'无法'解析'所谓'域名4) port_in_redirect['port来源'] on --> "是否携带端口"、"携带谁的端口"1、默认的情况下,是会在重定向的url后'自动添加nginx 处理server块当前站点监听'的端口2、会对服务器造成'潜在'的威胁,'后端端口暴露'出来,可能会被人直接对这个端口进行诸如CC类攻击5) 补充'说明'1、这几种'配置'方式不能显示随心所欲的'指定'2、通过改变'port'、'host',可能导致'重定向后'匹配一个新的'server'块6) 本次关注'$schme',经常会出现'如下报错':400 Bad Request The plain 'HTTP' request was sent to 'HTTPS' port根因： 'nginx'对应的'端口'监听的是'https',但是却用'http'访问场景1、nginx正常'配置 https 443',但是用户错误'http://www.wzj.com:443'访问场景2、nginx的'proxy_pass'是'https',但是后端只支持'http',导致转发'报错'$scheme是'http',但是'listen port'为4437) 浏览器如何处理'多个'Loation响应头 --> "待验证"
案例1： 'rewrite ^ kafka redirect;' 和 'rewrite ^ /kafka redirect;' 等价备注： 客户端['浏览器'、'curl']根据'上次'请求的'scheme、host、port'+'相对url'发起请求案例2： 多个重复'Location'响应头,浏览器和'curl'命令行'处理行为'不一样
++++++++++++++ "分割线" ++++++++++++++⑨ The palin HTTP request was sent to HTTPS port
目的： 必须明确'原理',也即'为什么'重定向后'https'变成了'http'?openssl非交互的生成自签名证书 利用openssl -config生成自签名证书
需求：openssl'非交互'生成'私钥'和'证书'openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \-keyout server.key -out server.crt -subj \"/C=CN/ST=HeNan/L=XinYang/O=devops/OU=unicorn/CN=ssl.wzj.com"
说明： 对于'自签名'证书,'curl'访问必须使用'(-k|--secure)'声明补充： https非'443[6443]'端口的时候,必须指定'port_in_redirect on','不要修改'默认行为报错原因：'HTTP请求'被发送到'HTTPS端口'排错手段： 看'配置文件'、看'请求方式'是否错误
#版本1.15.0及以下
listen 443;
ssl on;#版本1.15.0以上
listen 443 ssl;
listen 80; #这种可以'不同端口'监听同一服务 问题点: redirect涉及https跳转到http,这是一个'$scheme'非期望原因之一Kong X-Forwarded-Port 8443 问题
base标签导致The palin HTTP request was sent to HTTPS port
nginx不同版本ssl配置导致The plain HTTP request was sent to HTTPS port
proxy_paas协议错误导致The plain HTTP request was sent to HTTPS port
++++++++++ "不谈网站架构和需求都是流氓" ++++++++++问题现象: 请求'proxy1.wzj.com/kafka'报错: 'Client sent an HTTP request to an HTTPS server.'网站架构：用户 --> 'http' --> '反向代理' --> 'proxy_paas:http' --> 'nginx' 案例'模拟'场景： proxy_paas http://ssl.wzj.com:6443 -->但是'后端'只支持'https'协议补充现象： 被'代理'服务'报错'502,注意观察'error.log'的日志
nginx访问https跳转到http的解决方法
++++++++++++++ "涉及proxy模块解决$scheme的问题" ++++++++++++++解决： 通过'nginx'访问https'跳转到http'的解决方式1：需要'同时修改'nginx配置和程序 --> '不推荐'1) 在nginx代理中增加一个'proxy_set_header X-Forwarded-Proto $scheme'说明： 标志'用户请求'是http还是https2) 后端获取header决定'跳转'到http/https页面方式2： nginx代理中配置'proxy_redirect'proxy_redirect http:// $scheme://; 或 proxy_redirect http:// https://;场景: nginx的'proxy_pass'是'https',但是后端只支持'http',导致转发'报错'+++++++++ '题外话' +++++++++1) Jenkins根据请求头'proxy_ser_header X-Forwarded-Port $server_port'确定重定向端口2) mesher优先根据'proxy_ser_header X-Forwarded-Port $server_port'来进行'端口转发'
案例2： 不同的'url'访问,'proxy_redirect default'行为导致重定向的'协议$scheme'不一样
测试1说明： 由于'proxy_redirect'只剩下'Location: /wzj/kafka',经过'$scheme'等作用
案例3： '上游'Location传递错误的'$scheme',需要'proxy_redirect'对应修改 --> "省略"遗留： 对于'请求[流]链路'复杂的,需要'多服务协作',或者'抓包定边界'举例： 如果'上游服务器是nginx',其配置'absolute_redirect off';作为'proxy'的nginx处理？⑩ 你真的理解rewrite吗
1) 'rewrite ... last;',在location中,且location和rewrite的'匹配规则'能匹配到相同的URL2) nginx'最多'将进行'10次'循环匹配,并最终返回'500状态码'报错++++++++++++ rewrite flag'无'值与'有'值区别 ++++++++++++1) 当flag'有值'时,rewrite值'会中断',last会引发location重匹配;2) 当flag'无值'时,rewrite会继续往下走,最后一个rewrite值覆盖前面,在引发location重新匹配3) 未指定 flag 的情况与 flag=last 类似唯一'区别':是在同一层级中未指定 flag 的 rewrite 语句'不会终止后续'的 rewrite 匹配二 章神关于if和set解读
题外话： 之所以要'看原版英文'解读1) '一'是'原汁原味',避免层层传播产生'歧义'2) '二'是'掌握'单词',学习计算机'术语'描述① if工作原理
② 知识铺垫：CONTENT阶段模块的执行顺序
淘宝对CONTENT阶段的解读 nginx模块执行顺序
关注点：'content handle'、'NGX_HTTP_CONTENT_PHASE'阶段涉及的'模块'和'指令'1) nginx 'CONTENT'阶段中'默认'服务模块 --> 'static content' --> '兜底'[1]、当一个 location 中'未使用'任何 content 阶段的指令,没有模块注册'内容处理程序'时[2]、nginx 一般会在 content 阶段安排'三'个这样的'静态资源服务'模块[3]、'依次'是 'index' 模块、'autoindex' 模块、以及 'static' 模块1、index模块涉及'index'指令2、autoindex模块3、static模块涉及'root'、'alias'指令默认'CONTENT'阶段起作用的时机： 1、location 中'没有'使用运行在 CONTENT 阶段的模块指令2、也即'没有'模块'显示注册'这个 location 的"内容处理程序(content handler)"3、处理权便'自动'落到了在 CONTENT 阶段'垫底'的那 3 个'静态'资源服务模块2) 哪些'模快'会显示在CONTENT阶段'注册'内容处理程序? 这些CONTENT阶段模块的执行'顺序'?[1]、proxy模块、fastcgi模块、uwsgi模块在 CONTENT 阶段执行备注： 一般关注'proxy_pass'指令 补充： 将客户端过来的请求体'如果有的话'以'相应协议[转换]'完整的'转发'到后端服务进程[2]、ngx_echo 模块备注： 涉及'echo'、echo_exec、echo_location[3]、ngx_lua模块备注：涉及'content_by_lua'、'block_by_lua'等3) nginx 模块在'向 content 阶段注册配置指令'时一些'原理细节'[1]、'本质'上是在当前的'location'配置块中'注册'所谓的"内容处理程序(content handler)"[2]、每一个 location 只能有'一'个"内容处理程序"[3]、因此,当在 location 中同时使用'多个模块的 content 阶段指令'时[4]、只有'其中一个模块'能成功注册"内容处理程序",即只能'解析一条'相同的指令3) 通过'案例'重点讨论'多'个模块同时注册 content 阶段指令?注意： echo 、'proxy_paas'、'content_by_lua'同时出现的的'优先级',与'顺序'有关吗?强调： 应当'避免'在同一个 location 中使用'多个模'块的 content 阶段指令content和filter
③ set和proxy_paas杂谈
could not be resolved (3: Host not found)
+++++++++++++ "小结" +++++++++++++1) if block模块'没有'content handler2) 所以if block模块'继承'了'外部'的`proxy_pass`3) 最后在'if模块'里执行了这个`proxy_pass`,而不是在'外部'执行的`proxy_pass`案例来源
④ content handler不同层级
说明： 对比'上面案例'进行理解1) 此时'if block' 已经有了 'echo [content handler]';2) 不会'继承'外层的'proxy_paas'这个'content handler';
⑤ if中使用break
说明： '对比'案例理解
++++++++++++++++ "这个结论待验证,暂时遗留" ++++++++++++++++1) proxy模块在嵌入的'多个location间'的配置的'继承'扮演了关键的角色 --> '上面案例'2) 但是'其它模块[ngx_echo]'可能不会继承location'内嵌'的content handler --> '???'备注： 事实上,'大多数'content handler模块,包括upstream都'不支持'继承 --> '???'⑥ content handler相同层级
'临时'结论： 1) 同一'层级'的'content handler',由于只会'only 有一个 content handler执行'2) 最后的'content handler 覆盖'前面的备注： 具体'哪一个模块的指令'会胜出是'不确定'的3) 常见'content 指令': 'content_by_lua'、'echo'、'proxy_pass'4) 补充：echo 可以'使用多次','content_by_lua'、'proxy_pass'不行location /wzj {echo hello;echo world;}5) 最佳实践： '禁止'在同一个 location 中使用'多个模块的 content 阶段'指令
ngx_header_more模块的more_set_headers指令也会继承if块隐式创建的location
⑦ rewrite last和break标志位
1) last： 停止'当前'这个请求,并根据rewrite匹配的规则'重新'发起一个请求备注： 跳过原始请求的'location_rewrite'等后续阶段,'新请求'又从'find_location'开始执行补充： 新请求'保留'了原始请求的'什么'信息?2) break：相对last,break并'不会'重新发起一个请求备注：只是'跳过'当前的'rewrite阶段',并执行本请求'后续'的执行'阶段'
1) "内部跳转[internal]"本质上其实就是把当前的请求处理阶段'强行倒退'到 'find-config' 阶段备注：倒退回find-config阶段动作不是发生在rewrite阶段,而是发生在后面的'post-rewrite'阶段2) 以便'重新'进行请求 'uri[解码后]' 与 'location 配置块'的配对3) 如果在'server'配置块中直接使用 rewrite 配置指令对请求uri进行改写,则不会涉及'内部跳转'原因：因为此时uri改写发生在server-rewrite阶段,'早于'执行location配对的find-config阶段++++++++++ "404的真正原因" ++++++++++1) 404的原因'不是'没有定义对应的location,而是没有找到'对应的资源'2) 404的页面是'谁定义的'?[1]、nginx'自身'的默认格式还是'nginx 自定义[nginx配置有没有对404报错的处理]'[2]、如果'$upstream_status'为404,则是'后端服务'的
3种语言对nginx配置文件进行格式化 nginx配置文件格式化 变量漫谈
nginx的access日志打印16进制原因
⑧ 扩展:了解即可
location /test {echo_before_body "before...";proxy_pass http://127.0.0.1:8080/foo;echo_after_body "after...";
}location /foo {echo "contents to be proxied";
}请求： /test'
