摘要：但是对于一些设置了的项目，比如这种情况下当你用做反向代理的时候，就必须要转换一下了。多学习，多去关注一些底层的原理，才会发现自己理解的错误，望诸君共勉如果错误，欢迎指出
基本内容
Nginx做反向代理的时候，我们一般习惯添加proxy_cookie_domain配置，来做cookie的域名转换，比如
...
location /api {
proxy_pass https://b.test.com;
proxy_cookie_domain b.test.com a.test.com;
}
...
在之前的博客中我也是这么写的，但是最近在项目中发现，不配置这个属性，依然运转正常，背后冷风阵阵，我发现自己一直以来可能又理解错了这个选项，然后还在这给别人讲。。。
我们首先来看下proxy_cookie_domain的官方定义，
Syntax: proxy_cookie_domain off;
proxy_cookie_domain domain replacement;
Default:
proxy_cookie_domain off;
Context: http, server, location
This directive appeared in version 1.1.15.Sets a text that should be changed in the domain attribute of the “Set-Cookie” header fields of a proxied server response. Suppose a proxied server returned the “Set-Cookie” header field with the attribute “domain=localhost”. The directive proxy_cookie_domain localhost example.org will rewrite this attribute to “domain=example.org”.
翻译过来就是proxy_cookie_domain参数的作用是转换response的set-cookie header中的domain选项，由后端设置的域名domain转换成你的域名replacement，来保证cookie的顺利传递并写入到当前页面中，注意proxy_cookie_domain负责的只是处理response set-cookie头中的domain属性，仅此而已。
但是我们知道response在写set-cookie的时候，domain是一个可选项，并不是必填项，所以经常能看到如下这种情况
这个时候由于set-cookie本身就没有domain内容，proxy_cookie_domain也就不没有必要了，这也是为什么在部分项目中不配置proxy_cookie_domain依然正常的原因。但是对于一些设置了domain的项目，比如
这种情况下当你用nginx做反向代理的时候，就必须要转换一下了。
说到这里，我们再看看之前的错误理解：
“proxy_cookie_domain的作用是实现前后端cookie域名转换，保证顺利传递”
乍一看好像也没错，但是现在想想，理解还是不够啊，因为proxy_cookie_domain的作用是单向的，并不是双向转换的。我们先看下cookie的传递过程，盗一张图先(懒得画了。。。)
浏览器在发送请求的时候，会在request header中带上cookie项(有内容的话)，此时的cookie是一个字符串，一个key=value并用分号分割的字符串，
其中并不包含任何域名信息。这是因为浏览器在设置cookie选项的时候，所选取的内容都是缓存中接口域名下的。然后request的只要请求发送出去之后，cookie中有关domain信息其实是不存在的，它只是一个普通的字符串，随便proxy_pass到任何位置，都会正常携带下去。因此在前端到后端的request的过程中，proxy_cookie_domain是没用的
而server端在做响应的时候，通过set-cookie的domain属性，可以控制cookie的生效域名目标，做到诸如二级域名cookie分离等等，如果前端接收到的set-cookie的domain和当前域名不一致，或者一级域名不一致(二级域名可以共享一级域名下的cookie)，这个cookie在后续的通信中就是无效的，所以这里才需要去做domain的转换，也就是说response中set-cookie的domain转换才是有意义的，这也正是proxy_cookie_domain的作用所在。
当reseponse的set-cookie中domain不去设置时，cookie顺利传入浏览器中，浏览器会自动设置这个cookie的生效域名为当前域名。
和这个类似的还有proxy_cookie_path属性，同样的该属性仅作用在修改response set-cookie的path属性，而一般情况下，用的也比较少。
唠叨两句很多问题，有时候都是太过理所当然的以为它是怎么样的，并且生效了、达到目的了，我们就认为它是这样的了，但往往大脸就会在后面不期而至。多学习，多去关注一些底层的原理，才会发现自己理解的错误，望诸君共勉～
如果错误，欢迎指出～
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/40318.html
摘要：同时由于跨域了，就想利用的反向代理去处理一下跨域，但是在解决问题的同时，发现网上有些方案的确是存在一些问题，在这里总结一下基本配置，也聊一下常见的配置问题。 最近公司前后端分离，前端独立提供页面和静态服务很自然的就想到了用nginx去做静态服务器。同时由于跨域了，就想利用nginx的反向代理去处理一下跨域，但是在解决问题的同时，发现网上有些方案的确是存在一些问题，在这里总结一下基本配置...
摘要：同时由于跨域了，就想利用的反向代理去处理一下跨域，但是在解决问题的同时，发现网上有些方案的确是存在一些问题，在这里总结一下基本配置，也聊一下常见的配置问题。 最近公司前后端分离，前端独立提供页面和静态服务很自然的就想到了用nginx去做静态服务器。同时由于跨域了，就想利用nginx的反向代理去处理一下跨域，但是在解决问题的同时，发现网上有些方案的确是存在一些问题，在这里总结一下基本配置...
摘要：最近写了一些关于前后端分离项目之后，跨域相关方案的基本原理和常见误区的帖子，主要包括和反向代理。反向代理此时后端相当于不跨域，和正常请求一致，无需额外配置。 最近写了一些关于前后端分离项目之后，跨域相关方案的基本原理和常见误区的帖子，主要包括CORS和Nginx反向代理。这两种方案项目中都有在用，各有优缺，关于具体使用哪种方案，大家的观点也不大一致，本文主要就此展开一下，从前后端及服务...
摘要：同时若不想破坏已经做好的的话，也可以不使用，直接转发到服务器的内网应该也是可以的。这样在安全和效率高上就都能得到一定的提升。 之前写了一些nginx的东西，这次继续，主要使用upstream针对proxy_pass转发做个处理一般情况下我们在使用nginx反向代理的时候，都是如下配置， ... location /api { proxy_pass https://b.test.c...
摘要：作为前端开发，每次调试接口，把代码发到测试服务器，是很费时费事的一件事情。为了提高效率，想到了反向代理来解决这一问题。如何在手机上调试呢手机上不可能直接访问可以把手机和电脑连接到同一个网段，使用电脑的进行访问。 作为前端开发，每次调试接口，把代码发到测试服务器，是很费时费事的一件事情。为了提高效率，想到了nginx反向代理来解决这一问题。 接口地址：test.com 访问地址：loca...
阅读 2902·2023-04-26 02:14
阅读 3750·2019-08-30 15:55
阅读 1842·2019-08-29 16:42
阅读 2756·2019-08-26 11:55
阅读 2845·2019-08-23 13:38
阅读 480·2019-08-23 12:10
阅读 1308·2019-08-23 11:44
阅读 2789·2019-08-23 11:43
