记一次微信H5支付失败（网络环境未能通过安全验证，请稍后再试）解决方案

末蓝、 2022-01-15 02:21 365阅读 0赞

产品过来反馈，在调起微信支付时，报以下错误，上网搜了下，好像是IP不一致导致的，解决方案如下：

\--------------------------------------------------

官方解释：

![1223204-20190402000850025-215459311.png][]

首先我们要分清spbill\_create\_ip参数是干嘛的？

\---------spbill\_create\_ip 指的是终端ip，在APP和网页支付提交用户端ip，Native支付填调用微信支付API的机器IP。

那么归根结底，我们只要能获取正确的客户端ip,那么问题就可以解决，经过我艰苦卓绝的寻找，找到如下一个豪华版获取客户端ip的方法，只要用了它，java版H5支付就迎刃而解。如下：

/** 
         * 获取用户真实IP地址，不使用request.getRemoteAddr()的原因是有可能用户使用了代理软件方式避免真实IP地址, 
         * 可是，如果通过了多级反向代理的话，X-Forwarded-For的值并不止一个，而是一串IP值 
         *  
         *  获取终端ip(高配版)
         * @return ip
         */
        private String getIpAddr2(HttpServletRequest request) {
            String ip = request.getHeader("x-forwarded-for"); 
            System.out.println("x-forwarded-for ip: " + ip);
            if (ip != null && ip.length() != 0 && !"unknown".equalsIgnoreCase(ip)) {  
                // 多次反向代理后会有多个ip值，第一个ip才是真实ip
                if( ip.indexOf(",")!=-1 ){
                    ip = ip.split(",")[0];
                }
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getHeader("Proxy-Client-IP");  
                System.out.println("Proxy-Client-IP ip: " + ip);
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getHeader("WL-Proxy-Client-IP");  
                System.out.println("WL-Proxy-Client-IP ip: " + ip);
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getHeader("HTTP_CLIENT_IP");  
                System.out.println("HTTP_CLIENT_IP ip: " + ip);
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getHeader("HTTP_X_FORWARDED_FOR");  
                System.out.println("HTTP_X_FORWARDED_FOR ip: " + ip);
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getHeader("X-Real-IP");  
                System.out.println("X-Real-IP ip: " + ip);
            }  
            if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {  
                ip = request.getRemoteAddr();  
                System.out.println("getRemoteAddr ip: " + ip);
            } 
            System.out.println("获取客户端ip: " + ip);
            return ip;  
        }

扩展知识（x-forwarded-for）

X-Forwarded-For和相关几个头部的理解

*  **$remote\_addr**  
    是nginx与客户端进行TCP连接过程中，获得的客户端真实地址. Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求
 *  **X-Real-IP**  
    是一个自定义头。X-Real-Ip 通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP，这个设备可能是其他代理，也可能是真正的请求端。需要注意的是，X-Real-Ip 目前并不属于任何标准，代理和 Web 应用之间可以约定用任何自定义头来传递这个信息
 *  **X-Forwarded-For**  
    X-Forwarded-For 是一个扩展头。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP，现在已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中.

X-Forwarded-For请求头格式非常简单，就这样：

X-Forwarded-For:client, proxy1, proxy2

可以看到，XFF 的内容由「英文逗号 + 空格」隔开的多个部分组成，最开始的是离服务端最远的设备 IP，然后是每一级代理设备的 IP。

如果一个 HTTP 请求到达服务器之前，经过了三个代理 Proxy1、Proxy2、Proxy3，IP 分别为 IP1、IP2、IP3，用户真实 IP 为 IP0，那么按照 XFF 标准，服务端最终会收到以下信息：

X-Forwarded-For: IP0, IP1, IP2

Proxy3 直连服务器，它会给 XFF 追加 IP2，表示它是在帮 Proxy2 转发请求。列表中并没有 IP3，IP3 可以在服务端通过 $remote\_address 字段获得。我们知道 HTTP 连接基于 TCP 连接，HTTP 协议中没有 IP 的概念，$remote\_address 来自 TCP 连接，表示与服务端建立 TCP 连接的设备 IP，在这个例子里就是 IP3。

详细分析一下，这样的结果是经过这样的流程而形成的：

1.  用户IP0---> 代理Proxy1（IP1），Proxy1记录用户IP0，并将请求转发个Proxy2时，带上一个Http Header  
    `X-Forwarded-For: IP0`
2.  Proxy2收到请求后读取到请求有 `X-Forwarded-For: IP0`，然后proxy2 继续把链接上来的proxy1 ip**追加**到 X-Forwarded-For 上面，构造出`X-Forwarded-For: IP0, IP1`，继续转发请求给Proxy 3
3.  同理，Proxy3 按照第二部构造出 `X-Forwarded-For: IP0, IP1, IP2`,转发给真正的服务器，比如NGINX，nginx收到了http请求，里面就是 `X-Forwarded-For: IP0, IP1, IP2` 这样的结果。所以Proxy 3 的IP3，不会出现在这里。
4.  nginx 获取proxy3的IP 能通过$remote\_address获取到，因为这个$remote\_address就是真正建立TCP链接的IP，这个不能伪造，是直接产生链接的IP。**$remote\_address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。**

x-forwarded-for 实践研究：

1.  uwsgi\_pass的情况下，nginx 没有设置proxy\_pass x-forwarded-for: $proxy\_add\_x\_forwarded\_for;  
    如果请求头传了XFF，在flask里面能正常读取请求头里面的XFF,就是当是一个普通的头读出；如果header不传这个XFF的话，就读不到
2.  proxy\_pass 情况下

*  没有传 \# proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for 的话，跟上面的uwsgi\_pass 一样，都是在没有设置header XFF情况下，读不到。
 *  如果传了 proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for， header 不传xff 的话，也是可以在程序里面读到Xff 头： X-Forwarded-For: 10.0.2.2 （这个IP就是真正连上nginx 的IP， 也就是$remote\_address），因为这句proxy\_set\_header 会让nginx追加一个$remote\_address到XFF。
 *  header 传xff的话， 程序里面可以读到Xff 头： X-Forwarded-For: 188.103.19.120, 10.0.2.2 （第一个是我自己编的，第二个是$remote\_address），nginx还是会因为proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for 这句而追加$remote\_addr到XFF。

总结：

1.  只要nginx前端（例如lvs， varnish）转发请求给nginx的时候，带了x-forwarded-for ,那么程序就一定能读到这个字段，如果nginx还设置了proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for， 那么程序能读到XFF是：ip0, ip1 (客户端Ip，lvs或者varnishIP)。 如果nginx没有设置，那么nginx还是会原样把http头传给程序，也就是说程序也能读到XFF，而且XFF就是ip0 客户端IP。
2.  proxy\_pass 设置这个头 proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for; 是站在一个作为代理的角度把。能继续传输多级代理的头。
3.  nginx的日志格式写了$http\_x\_forwared\_for 说明前端（lvs）确实传了这个头过来。所以是程序是读取到的
4.  uwsgi\_pass 不能设置 proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for; 这个头，是因为这个头是对http代理来说，用来传递IP的，uwsgi 不可能充当一个代理。
5.  nginx->程序，这里其实有两个链接过程，其他IP与nginx的TCP链接， nginx与程序的TCP链接。所以$remote\_addr都是对各自来说的。  
    程序的remote\_addr: remote\_addr 127.0.0.1 (跟它链接的是nginx 内网127.0.0.1)  
    nginx的remote\_addr : X-Real-Ip: 10.0.2.2 （跟它链接的是我的电脑，IP 10.0.2.2）

1.  对程序来说，读取的request.remote\_addr 也永远是直接跟他链接的ip， 也就是反向代理nginx
2.  The access\_route attribute uses the [X-Forwarded-For][][ ][X-Forwarded-For][header][X-Forwarded-For], falling back to the REMOTE\_ADDRWSGI variable; 也就是说access\_route默认读取XFF头，如果没有，降级读取WSGI的REMOTE\_ADDR变量,这个 WSGI的REMOTE\_ADDR变量 就是 $remote\_addr
3.  request.envron 是WSGI的变量，都是wsgi server转过来的，普通的头都是加了HTTP\_前缀的 ，包括proxy\_set\_header Host $host:8000;  
    proxy\_set\_header X-Forwarded-For $proxy\_add\_x\_forwarded\_for;  
    添加的头都会出现在处理，因为他们就是普通的http头
4.  LVS->nginx的情况下， 请求的时候主动加XFF，程序读取的时候没显示。因为LVS设置XFF的时候，直接把直连的IP赋值给LVS，忽略掉所有本来有的XFF，要从LVS这里开始。 所以程序读到的XFF是 ：XFF headers 218.107.55.254, 10.120.214.252  
    前面的是我的IP， 后面的是LVS的IP

{
      "wsgi.multiprocess": "False",
      "SERVER_SOFTWARE": "Werkzeug/0.11.10",
      "SCRIPT_NAME": "",
      "REQUEST_METHOD": "GET",
      "PATH_INFO": "/api/get_agreement_url/",
      "SERVER_PROTOCOL": "HTTP/1.0",
      "QUERY_STRING": "",
      "werkzeug.server.shutdown": "<function shutdown_server at 0x7f4a2f4e5488>",
      "CONTENT_LENGTH": "",
      "SERVER_NAME": "127.0.0.1",
      "REMOTE_PORT": 58284,
      "werkzeug.request": "",
      "wsgi.url_scheme": "http",
      "SERVER_PORT": "6000",
      "HTTP_POSTMAN_TOKEN": "666cfd97-585b-c342-f0bd-5c785dfff27d",
      "wsgi.input": "",
      "wsgi.multithread": "False",
      "HTTP_CACHE_CONTROL": "no-cache",
      "HTTP_ACCEPT": "*/*",
      "wsgi.version": "(1, 0)",
      "wsgi.run_once": "False",
      "wsgi.errors": "",
      "CONTENT_TYPE": "",
      "REMOTE_ADDR": "127.0.0.1",
    
      "HTTP_CONNECTION": "close",
      "HTTP_USER_AGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36",
      "HTTP_ACCEPT_LANGUAGE": "zh-CN,zh;q=0.8,en;q=0.6",
      "HTTP_X_FORWARDED_FOR": "10.0.2.2",
      "HTTP_ACCEPT_ENCODING": "gzip, deflate, sdch",
      "HTTP_HOST": "[test.mumu.nie.netease.com:8000](http://test.mumu.nie.netease.com:8000/)",
    
    }

$proxy\_add\_x\_forwarded\_for; nginx的这个变量含义就是，每次都追加$remote\_address 到 xff头，如果xff头不存在，那么xff就被设置成跟$remote\_address 一样了。如果本来就存在，就追加了 ip1, ip2这样的形式

问题：

1.  为什么lvs-nginx ， nginx的日志记录$http\_x\_forwarded\_for还是可以的？

参考文献：1、[https://www.cnblogs.com/hedongfei/p/10640139.html][https_www.cnblogs.com_hedongfei_p_10640139.html]

2、https://www.jianshu.com/p/15f3498a7fad

[1223204-20190402000850025-215459311.png]: /images/20220114/8f70b465b56c4f2d90d221d0b71f6156.png
[X-Forwarded-For]: http://en.wikipedia.org/wiki/X-Forwarded-For
[https_www.cnblogs.com_hedongfei_p_10640139.html]: https://www.cnblogs.com/hedongfei/p/10640139.html