Nginx 代理解决跨域问题分析（使用nginx解决跨域问题）

当你遇到跨域时，不要马上复制去尝试。请详细选择这个问题领域再处理。我相信会帮助到你的。

分析前准备：

前端网站地址：http://localhost: 8080

服务端网址：http://localhost: 59200

首先保证服务端是没有跨域处理的，先用邮递员测试服务端接口是正常的

当网站8080去服务端接口的时候，就跨域问题，如何解决？你能理解的原理）。

跨域主要涉及4个响应头：

Access-Control-Allow-Origin用于设置允许跨域请求源地址（预检请求和正式请求在跨域请求源地址验证）

Access-Control-Allow-Headers 跨域允许的特殊信息字段验证（只携带在预检请求）

Access-Control-Allow-Methods跨域允许的请求方法或说HTTP动词 （只在预检请求验证）

Access-Control-Allow-Credentials是否允许跨域使用 cookie，如果要跨域添加此请求响应头，设置为真（设置或不设置，都不会影响请求发送使用 cookie，滥用值在跨域需要携带，但如果设置，域检测请求和正式生效）。 ，因为有很多方案可以代替。

网上很多文章告诉你直接Nginx添加这几个响应头信息但是解决域，当然这个情况都是解决问题，我相信很多，明明有配置域，也同样会报跨域问题。

什么是预检？其中：当发生跨域情况的时候，览器先了解服务器，当前网页肯定属于的域名是否在服务器的许可范围内，以及可以有哪些HTTP服务器和头信息字段使用。只要有答复，浏览器就会发出正式的 XMLHttpRequest 请求，否则就会报错。如下图

动手模拟：

Nginx代理端口：22222，配置如下

服务器{
        听       22222 ;
        server_name  本地主机；
        位置  / {
             proxy_pass   http://localhost:59200;
        }
}

测试是否代理成功，通过Nginx代理端口2222再次访问接口，可以看到如下图通过代理后接口也能正常访问

开始使用网站8080访问Nginx代理后的接口地址，报错情况如下↓↓↓

情况1：

从源“http://localhost:8080”访问“http://localhost:22222/api/Login/TestGet”的 XMLHttpRequest 已被 CORS 策略阻止：对预检请求的响应未通过访问控制检查：否' Access-Control-Allow-Origin ' 标头存在于请求的资源上。

通过错误信息可以很清楚地定位到错误（注意看标红部分）priflight 说明是个预请求CORS 机制跨域会首先预检（OPTIONS），该请求成功后会发出一个请求。设计不支持对 CORS 的服务器提供标准，以保护 CORS 的服务器

错误信息，可以得到预检请求的响应，我们可以通过下面的方式来修改我们的访问权限-控制-允许来源，错误，部分为添加信息就好了。补什么，很简单明了

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
            add_header Access-Control-Allow-Origin 'http://localhost:8080' ;
           proxy_pass   http://localhost:59200;
        }
    }

哈哈，当满怀欢喜地以为能解决之后，还是发现了同样的问题

的配置没什么问题，我们的问题在Nginx,下图链接http://nginx.org/en/docs/http/ngx_http_headers_module.html

add_head指令最后用于添加返回头字段当有效，且仅当状态码为系列想要的那些时候。 -Control-Allow-Origin 这个信息需要总是加，其他的不加总是带着回来），那我们加上试试

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
            add_header Access-Control-Allow-Origin 'http://localhost:8080'总是；
           proxy_pass   http://localhost:59200;
        }
    }

修改了配置后，发现生效了，当然不是跨域就解决了，是这个问题已经解决了，因为报错变了

情况2：

从源“http://localhost:8080”访问“http://localhost:22222/api/Login/TestGet”处的 XMLHttpRequest 已被 CORS 策略阻止：对预检请求的响应未通过访问控制检查：它没有 HTTP ok 状态。

通过报错信息提示可以发现，是没有跨浏览器默认行为的请求（选项请求）确定状态请求码，此时再文件，当请求为选项时，浏览器返回一个状态码（一般是204）

 服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
            add_header Access-Control-Allow-Origin 'http://localhost:8080'总是；
           if ( $request_method = 'OPTIONS' ) {
                返回 204 ;
           }
           proxy_pass   http://localhost:59200;
        }
    }

当配置完成后，发现报错信息变了

情况3：

从源“http://localhost:8080”访问“http://localhost:22222/api/Login/TestGet”处的 XMLHttpRequest 已被 CORS 策略阻止：Access-Control-Allow不允许请求标头字段授权- 预检响应中的标头。

英文预预响应访问权限--Allow-Headers 控制情况中会发生情况后的响应头信息授权（各种不一样的情况下发生跨域，在自定义的头信息是要求添加的头信息，需要添加到响应请求头） Access-Control-Allow-Headers中，以便浏览器知道信息的携带是服务器承认的，我这里携带的是授权，其他的可能是token之类的，知道缺什么加什么问题），了，修改配置文件，添加其他的部分，然后再尝试

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
            add_header Access-Control-Allow-Origin 'http://localhost:8080'总是；
           if ( $request_method = 'OPTIONS' ) {
                add_header Access-Control-Allow-Headers 'authorization' ; #为什么写在如果里面不是后续Access-Control往下写因为这里只有预检请求-Allow-Origin检查
               返回 20 ;
          } 
        proxy_pass http://localhost:59200;
    }
}

此时报错问题又回到当时的情况1

经过测试验证，只要 if ($request_method = 'OPTIONS') 里面写了 add_header ，当为预检请求时外部配置的舱室，为什么？↓↓。

官方文档是这样说的：

可能有几个 add_header 指令。当且仅当在当前级别上没有定义 add_header 指令时，这些指令才从上一层继承下来。

英文就是当前层级无add_header 指令时，则继承上一级的add_header。相反，如果当前层级有add_header，就应该无法继承上一级的add_header。

配置修改如下：

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
             add_header Access-Control-Allow-Origin 'http://localhost:8080'总是；
            if ( $request_method = 'OPTIONS' ) {
                 add_header Access-Control-Allow-Origin 'http://localhost:8080' ;
                add_header Access-Control-Allow-Headers 'content-type,authorization' ;
                返回 204 ;
            }
            proxy_pass   http://localhost:59200;
        }
    }

此时改完发现跨域问题已经解决了，

以上虽然解决了跨域问题，但是考虑可能Nginx版本更新，不知道这个规则会不会被修改，考虑到这样的法可能会携带两个Access-Control-Allow-Origin，这种情况也是应该的，下面会写。所以配置适当修改如下：

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
             if ( $request_method = 'OPTIONS' ) {
                 add_header Access-Control-Allow-Origin 'http://localhost:8080' ;
                add_header Access-Control-Allow-Headers 'content-type,authorization' ;
                返回 204 ;
            }
            if ( $request_method != 'OPTIONS' ) {
                 add_header Access-Control-Allow-Origin 'http://localhost:8080'总是;
            }
            proxy_pass   http://localhost:59200;
        }
    }

结束，继续聊↓↓

情况4：

早期比较的 API 域只可能出现和出现跨域 POST-GET 和 GET 请求控制-Allow 的默认方法这个请求响应头域只支持，当出现其他请求类型的异常时，同样会出现跨域。

例 如，这里我请求从最初的 GET API 请求改成的方式，在一次请求上会发生错误。

从源“http://localhost:8080”访问“http://localhost:22222/api/Login/TestGet”处的 XMLHttpRequest 已被 CORS 策略阻止：Access-Control-Allow-Methods 不允许方法 PUT在预检响应中。

报错内容也讲的很清楚，在这个请求中，PUT方法是希望在跨域中使用的，我们需要改下Access-Control-Allow-Methods的配置（缺什么加上什么，这里我只了PUT，可以自己加全一点），让浏览器知道服务端是允许的

服务器{
    听       22222 ;
    server_name  本地主机；
    location   / {
         if ( $request_method = 'OPTIONS' ) {
             add_header Access-Control-Allow-Origin 'http://localhost:8080' ;
            add_header Access-Control-Allow-Headers 'content-type,authorization' ;
            add_header访问控制允许方法'PUT'；#为这样只加在这个if中，不再下面的如果也加？因为这里只有预检请求会同意，当然你加也不会。
            return  204 ;
        }
        if ( $request_method != 'OPTIONS' ) {
             add_header Access-Control-Allow-Origin 'http://localhost:8080'总是;
        }
        proxy_pass   http://localhost:59200;
    }
    }
 

这里注意一下，改成PUT后，Access-Control-Allow-Headers请求行响应头又会自动校验content-type这个请求头，和情况3是一样的，缺什么补就补了。啥不加content-type，但是简单报如下错误。（想的话，Access-Control-Allow-Headers和Access-Control-Allow-Methods可以*，表示全都匹配。Access-Control-Allow-Origin就不建议建议了设置成*了，为了安全考虑，限制域名是很有用的。）

都加上方法后，问题了，这里报405是我的服务端接口开放了GET，没有开放PUT，而此时这个状态只是我用PUT去解决这个问题，所以会返回码。

情况5：

再有一种情况，就是把服务端跨处理下跨处理了自己在处理，但是随便找个地方解决问题就可以了项目代码选项自己贴上自己的状态，没有回应可能处理的不完整，没有回应的可能处理不完全到点上，负责人全过程的代码所用的方法，添加请求处理的方法，添加请求等，导致Nx再用通用的配置可能会报以下异常）

从源“http://localhost:8080”访问“http://localhost:22222/api/Login/TestGet”处的 XMLHttpRequest 已被 CORS 策略阻止：“Access-Control-Allow-Origin”标头包含多个值 '*, http://localhost:8080'，但只允许一个。

英文就是此时Access-Control-Allow-Origin请求响应头修改了返回多个，而只允许有一个，这种情况当然配置了Access-Control-Allow-Origin这个配置就可以了，不过遇到这种情况，建议Nginx配置和服务端自己解决跨域只选其一。（这里如果按我上面的写法，如果$request_method = 'OPTIONS'里面的Access-Control-Allow-Origin可以不能删除，删除！= 'OPTIONS'里面的预存就好了，因为这里是检测请求直接就转了，请求不会再转发到59200服务，所以如果也删除了，希望报和情况1一样的错误。为什么说要不服务端代码解决跨域问题，代理就不是Nginx，不要混着搞，要解决网上找不到原理的人，贴一段代码就很可能解决不了问题）

↓ ↓ ↓ ↓ ↓

再贴一份自己的完整装备（*号根据'喜'重新贴）：

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
             if ( $request_method = 'OPTIONS' ) {
                 add_header Access-Control-Allow-Origin 'http://localhost:8080' ;
                add_header Access-Control-Allow-Headers '*' ;
                add_header访问控制允许方法'*' ;
                add_header Access-Control-Allow-Credentials 'true' ;
                返回 204;
            }
            if ( $request_method != 'OPTIONS' ) {
                 add_header Access-Control-Allow-Origin 'http://localhost:8080'总是;
                add_header Access-Control-Allow-Credentials 'true' ;
            }
            proxy_pass   http://localhost:59200;
        }
    }

或者：

服务器{
        听       22222 ;
        server_name  本地主机；
        location   / {
             add_header Access-Control-Allow-Origin 'http://localhost:8080'总是；
            add_header Access-Control-Allow-Headers '*' ;
            add_header访问控制允许方法'*' ;
            add_header Access-Control-Allow-Credentials 'true' ;
            if ( $request_method = 'OPTIONS' ) {
                返回 204 ;
            }
            proxy_pass   http://localhost:59200;
        }
    }

这是最后一篇解决跨领域遇到问题的解决过程，如果认真研究了问题，我相信应该能够理解，在实际使用中自己解决该问题，并且，能够帮助大家，以上内容都是自己理解自己码出来的，如果不理解测试的地方，望大家指正。