使用 nps 内网穿透 使用域名代理 然后用 nginx 反向代理 这样就可以使用 80 端口了

然后拿去开发微信 去微信授权 在授权后设置了一个比较大一点的 session 数据

然后美国服务器在取不到设置的 session 数据（如果一直 session 会出现无限循环授权或者页面 502 （后者我也不知道什么鬼））

然后在两个月断断续续的测试排查中，发现设置了数据量比较的 session 数据就会出现 session 丢失，才知道的这个情况。

当代码把设置的 session 数据弄得小一点就好了页面就能正常运行，不改代码大的 session 数据在生产环境也是能正常跑的，问题处在了 nginx 反代身上，初步怀疑是反代无法转发过大的数据导致的。不过让我疑惑的是，直接使用原始端口（非反代）也是相同的情况，这样又说明不是反向代理的问题了。

问题是 nps 的转发过大的数据能力不够嘛？

针对反代的情况，尝试了几种网上的解决办法都失效，都是修改 nginx 配置。

这种设置为 100M 了，还是不行。

# 开启代理缓冲区
proxy_buffering on;
# 响应头的缓冲区设为 32k
proxy_buffer_size 100m;
# 网页内容缓冲区个数为 4，单个大小为 128k
proxy_buffers 12 10m;
# 缓冲区临时文件最大为 256k
proxy_busy_buffers_size 100m;

client_header_buffer_size 100m;
large_client_header_buffers 4 10m;

求助各位。

client max body size

session 不是保存在服务端的吗？

client_max_body_size 的值是 1024M

session 不是在服务端的吗

如果 502 就说明是后端出错吧，没看过后端错误日志吗？如果后端 buffer 太小，前端设置再大也白整。

单看描述也没什么思路，“过大”是指多大？
再试试改这个参数 client_header_buffer_size，默认 1k 。
有没有看看 nginx 的 error log 的保存？

贴点日志啥的吧，上面都是你的怀疑和你觉得的东西，分析意义不大

难道你说的是 cookie-session?

可能是 cookie 的 4k 限制？

nginx 没详细的日志
如果出现 502 就会这样 如果没用出现就又跳转走了 场景是微信网页授权登录 登录后设置 session session 是 laravel(PHP 框架)的一个模型 如果这个模型转成数组就可以顺利通过
- - [13/Feb/2021:14:22:27 +0800] "GET /pay?code=061oQl200p9adL1vqQ200OUkZU3oQl2g&state=011e4a0e351e539aeb9ee6e4299bf6bb HTTP/1.1" 502 150 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.3 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1 wechatdevtools/1.03.2101150 MicroMessenger/7.0.4 Language/zh_CN webview/16131902376102325 webdebugger port/49544 token/db7a49d5605393c8578b96711be0beae"

至于 laravel 框架的 session 机制 这个我还没仔细查过

@IvanLi127

有没有可能是反代机什么 offload 特性导致……

nginx 里没有 session 这个概念，这是个无效的信息。
Web 开发里提到的 session，为了安全考虑一般也是保存在服务器上，不需要返回给前端。
如果你指的是 cookie，推荐用 google 查一下，关键词：chrome cookie size limit 。cookie 不要太多。
另外，最关键的一点，看到你在调试时直接把 nginx 里几个参数设置成 100m （期望能“碰巧”找到原因？其实在大部分情况下不可能达到这个量级，这么尝试性的设置没有任何意义）。这不是个好习惯。

跟 header size 无关
因为触及这个限制的时候会发生 413 错误而不是莫名其妙的故障

过大的 session 是什么意思？
我没记错的话 session 的实现是服务端分配个 key 给浏览器（ cookies ），记录 session 的 ID 。
后续的请求浏览器都携带该 cookies （ session id ）发送给服务端。
session 具体保存的内容是保存在服务端的，所以 session 过大和过小估计和这个关系不大吧？
另外其实你可以自己核查一下，浏览器是否有收到 set-cookie 的 response，后续的 request 是否有带该 XXXsessionXXX=之前得那个 cookie 。