Nginx双层域名时 iframe嵌入/跳转页面的处理过程

背景

两年前在上一家公司内遇到一个Nginx的问题
当时的场景是 双层nginx代理时(一层域名侧, 一层拆分微服务的网关层)
程序里面会打开一个嵌套的iframe, 便于进行缩放. 

但是此时因为只能就近获取 第二层反向代理的 upstream的域名信息. 
导致打开的是一个 虚拟的upstream的域名. 
外部用户打开时就是提示 http(s)://upstream_server/some/url can not open /404 等问题. 
当时耗费了一个中午才在多位同事的协助下解决问题. 
方式方法是 proxy_redirect的方式进行 第二层代理传给域名侧代理的(upstream_server)虚拟机域名修改为 域名侧代理的实际地址信息(外网域名).

问题描述比较绕, 但是解决方法还是比较简单的. 

解决方法-之一

在 域名侧的负载均衡出增加如下信息:
注意 我这个里面包含了较多的内容, 为了安全以及其他. 

    location / {

    proxy_set_header  Host $http_host ;
    proxy_http_version 1.1;
    proxy_read_timeout 3600s;
    # websocket协议升级 可选
    #proxy_set_header Upgrade $http_upgrade;
    #proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;


    proxy_pass http://192.168.xx.xx/;

    proxy_redirect http://Second_level_proxy_server_name  http://Your.corporation.com ;
   }

解决方法之二

需要说明, 这个地方有个坑,坑了我三个小时.

当年发现问题是, 因为项目上的nginx配置文件是自己从头到尾跟上家公司最辛苦最靠谱的栋哥一起写的.
为了显得专业(我一直认为, 钱不给够就不是真专业)
自己每一层都写了很多冗余的配置节(这锅不是栋哥的也不是挖到雷的东哥的, 是我的)

而这次的配置文件都非常简洁明了
我其实挺喜欢这种格式的. 但是没想到因为 缺少了一些必要的参数条件,导致一直无法调通. 
所以解决方法之二就是, 必须要在靠近应用的那一侧的负载均衡处 增加如下配置. 
不然可能跟我一样浪费一晚上刷历史公众号的时间. 

注意不增加很多proxy_set_header的设置, 可能总是无法正确跳转, 无比切记. 

解决方法之二

upstream Second_level_proxy_server_name {
    server 192.168.xx.yy:1234;
}

location /your_api_path/ {
    proxy_set_header  Host $http_host ;
    proxy_http_version 1.1;
    proxy_read_timeout 3600s;
    # websocket 协议升级, 可选
    #proxy_set_header Upgrade $http_upgrade;
    #proxy_set_header Connection "upgrade";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_pass http:///Second_level_proxy_server_name/your_api_path/;
    expires -1;
}

总结-chatgpt的解释

proxy_pass和proxy_redirect是Nginx中用于代理服务器的两个指令。

proxy_pass指令用于将请求转发到后端服务器。它指定了代理服务器将请求转发到的后端服务器的地址。例如：

location / {
    proxy_pass http://backend_server;
}
在上面的示例中，所有以"/"开头的请求将被转发到backend_server指定的后端服务器。

proxy_redirect指令用于修改从后端服务器返回的响应头中的Location标头。它允许你替换响应中的网址，以便将客户端重定向到正确的地址。例如：

proxy_redirect http://backend_server/ http://frontend_server/;
在上面的示例中，如果后端服务器返回一个重定向的响应，其中包含"http://backend_server/“，则Nginx会将其重定向到"http://frontend_server/”。

这些指令通常一起使用，以便在Nginx代理服务器上配置反向代理。proxy_pass指令用于转发请求，proxy_redirect指令用于修改返回的响应，以便正确地重定向客户端。

总结-个人版

pass 其实是指向的下一层.
redirect 其实是上一层帮下一层处理下一层不知道的事情. 

理论上 下层反向代理 是可能不知道上层方向代理的域名的
因为域名可以不是一个, 并且可能经常会变. 
写死了域名时不合适的. 在遇到各种变化时太过笨重. 

所以pass 实现基本的 反向代理的需求
redirect 实现有域名变化时的需求. 

nginx 其实非常复杂. 不管是性能还是配置调优可以直接说的地方非常多.

今天这三个小时 其实看了不少文档, 顺便发现自己之前真是笨(现在也是)
使用 location = / 就可以非常简单的设置一个 默认首页了
而不会影响具体的反向代理设置. 

自己的思维还是受限, 需要继续开拓, 继续学习.