BitrixCMS栈下PHP会话24-55分钟无操作失效超55分钟正常问题咨询

非代码类可能诱因 #

• 分层会话过期逻辑冲突：当前架构中Nginx层、Apache层可能单独配置了会话缓存/ Cookie校验规则，和PHP层的过期策略错位。比如24~55分钟区间刚好命中Nginx侧的会话缓存失效阈值，触发反向代理层主动踢掉会话，而超过55分钟后Nginx侧的缓存规则不再生效，直接把请求透传给后端PHP处理。
• 会话存储介质的GC（垃圾回收）策略异常：如果PHP会话存储在文件、Redis、Memcached中，存储层本身的过期/淘汰规则和PHP配置不一致。比如会话文件的GC概率设置不合理，24~55分钟区间刚好触发了随机GC，把存活的会话清掉了，而超过55分钟的会话刚好躲过了GC轮次，或者存储层对超过一定时间的键有单独的保留策略。
• BitrixCMS内置会话管理机制干扰：Bitrix本身有独立的会话有效期控制、会话轮换规则，会覆盖PHP原生的会话配置，可能存在「空闲会话超过X分钟轮换ID、超过Y分钟才彻底销毁」的逻辑，刚好24~55分钟处于ID轮换区间，超过55分钟反而到了不轮换直接保留的特殊逻辑区间（比如后台设置了长时间未操作的用户标记为免验证，不再刷新会话ID）。
• 服务器时间不同步：如果Nginx、Apache、PHP所在的服务器（或容器）时间不一致，会导致各层计算会话过期时间的基准不对，出现24~55分钟区间的时间差刚好命中过期判断，超过55分钟后时间差反而不满足过期条件的反常情况。
• Cookie作用域/路径规则冲突：可能存在两个相同名称的PHPSESSID，作用域或者路径不同，24~55分钟区间请求携带的是作用域更小的过期Cookie，触发服务端返回新Cookie，超过55分钟后请求自动携带了另一个作用域更大的未过期Cookie，看起来像是旧会话被保留了。

影响会话过期逻辑的核心配置项 #

PHP原生配置 #

• session.gc_probability、session.gc_divisor：两者的比值是GC触发概率，概率过高会导致会话被随机清理，概率过低会导致过期会话长期残留
• session.gc_maxlifetime：PHP认为会话过期的最大生命周期，单位秒，默认1440（24分钟），刚好对应问题里的24分钟起始阈值
• session.cookie_lifetime：PHPSESSID Cookie的客户端有效期，设置为0的话会在浏览器关闭时失效，设置为固定值的话会和服务端过期时间形成错位
• session.save_handler：会话存储方式，文件、Redis、Memcached等不同存储的过期逻辑有差异
• session.use_strict_mode：严格模式下服务端会拒绝未初始化的会话ID，可能和自定义会话逻辑冲突

Apache配置 #

• mod_session模块相关配置：SessionMaxAge设置会话最大有效期，SessionCookieName如果和PHP的SESSID同名会覆盖规则
• mod_rewrite规则：可能存在针对特定时间间隔请求的重写规则，修改了会话传递逻辑

Nginx配置 #

• proxy_cache相关配置：如果开启了会话级缓存，proxy_cache_valid设置的缓存时间会影响会话透传逻辑
• proxy_cookie_path/proxy_cookie_domain：修改Cookie的路径和域，可能导致会话匹配异常
• ngx_http_userid_module模块：如果开启了用户ID设置，可能和PHPSESSID冲突

BitrixCMS配置 #

• 后台「设置-站点设置-安全」中的会话有效期设置、会话ID轮换设置
• php_interface/dbconn.php中自定义的会话处理函数配置
• 组件或模块中注册的OnBeforeSessionStart、OnAfterSessionStart事件回调的会话控制逻辑

内容的提问来源于stack exchange，提问作者Lex