我之前维护HTTPS项目时也碰到过类似的CaptchaMvc兼容问题，结合对浏览器referrer政策和这个验证码包的了解，给你拆解下原因和可行的解决办法：

问题根源 #

Chrome对referrer-policy: none的执行逻辑比IE/Edge更严格——当设置这个值时，Chrome会完全不发送Referer请求头。而CaptchaMvc 1.5.0的默认配置里，会校验请求的Referer头来确认验证码请求的合法性，没有Referer头的情况下，服务端会拒绝生成/返回验证码图片。

反观IE/Edge，它们对referrer-policy: none的兼容性处理更宽松，依然会发送必要的Referer信息，所以验证码能正常加载。

可行解决方案 #

1. 调整referrer-policy为更兼容的安全值 #

如果业务对referrer的限制不是必须用none，推荐改用strict-origin-when-cross-origin。这个值既符合HTTPS的安全要求，又会在同源请求或跨源请求时发送精简的Referer信息，Chrome就能正常加载验证码了。

你可以在HTTP响应头里设置：

referrer-policy: strict-origin-when-cross-origin

2. 关闭CaptchaMvc的Referer校验 #

如果必须保留referrer-policy: none，可以修改CaptchaMvc的全局配置，让它忽略Referer头的校验。在Global.asax的Application_Start方法里添加以下代码：

// 关闭Referer验证
CaptchaUtils.DefaultCaptchaManager.ValidationSettings.IgnoreReferrer = true;

这样验证码服务端就不会再校验Referer头，Chrome下也能正常显示验证码。不过要注意：关闭Referer校验会小幅降低验证码的防刷安全性，建议结合其他验证逻辑（比如IP限制、请求频率限制）来弥补。

3. 改用Cookie存储验证码信息（替代Referer校验） #

另一种更安全的方式是把验证码的验证信息存在Cookie里，而不是依赖Referer头。同样在Global.asax的Application_Start中配置：

// 使用Cookie存储验证码数据，替代Referer校验
CaptchaUtils.DefaultCaptchaManager.SetCaptchaStore(new CookieCaptchaStore());

这种方式既保留了验证码的安全性，又不依赖Referer头，完美适配referrer-policy: none的场景。

额外注意事项 #

• 修改配置后，记得清除Chrome的缓存再测试，有时候旧的缓存会导致政策不生效；
• 如果你使用Web.config配置自定义头，确保referrer-policy值拼写正确（注意区分none和no-referrer，Chrome对这两个值的处理有细微区别）。

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