is_https()仅检查$_server[‘https’]是否严格等于”on”，不验证证书、端口或代理头；nginx默认不设置该变量，cloudflare等需手动透传x-forwarded-proto并启用对应fallback。
is_https() 函数到底检查什么
is_https() 不是检查当前请求“是否应该走 HTTPS”，而是单纯读取几个服务器变量，判断「此刻 CGI 环境中是否报告了 HTTPS = on」。它不验证证书、不探测端口、不重定向，也不管 Nginx 反向代理有没有透传头。
常见错误现象：is_https() 在 Nginx + PHP-FPM 部署下总返回 false，哪怕浏览器地址栏明明是 https://；或者在 Cloudflare 后面直接失效。
- 它优先看
$_SERVER['HTTPS']是否严格等于"on"（注意是字符串 “on”，不是 1 或 true） - fallback 到检查
$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'—— 但 CodeIgniter 默认**不启用**这个 fallback，除非你手动改过system/core/URL.php或用了补丁版 - 完全忽略
$_SERVER['SERVER_PORT'] == 443这类端口判断（有些框架会用，CI 不会）
为什么本地开发和线上行为不一致
根本原因是 Web 服务器配置差异导致 $_SERVER 变量内容不同。apache mod_ssl 默认设 HTTPS=on，而 Nginx 默认什么都不设。
使用场景：你在本地用 Apache XAMPP 测试正常，一上阿里云 ECS（Nginx）就失效，不是代码问题，是环境没对齐。
- Apache：通常自动设置
$_SERVER['HTTPS'] = 'on' - Nginx：必须显式配置
fastcgi_param HTTPS on;，否则该字段根本不存在 - Cloudflare / CDN：需确保开启「Always Use HTTPS」并配置
proxy_set_header X-Forwarded-Proto $scheme;，且后端 PHP 要信任该 header（CI 原生不信任）
安全又兼容的替代写法
别硬修 is_https()，直接绕过它写一个更可控的判断。尤其当你的应用跑在反向代理后面时，这是唯一靠谱做法。
示例（放在 application/helpers/custom_helper.php 中）：
function is_https_safe() { if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') { return true; } if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { return true; } if (isset($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] === 'on') { return true; } return false; }注意：HTTP_X_FORWARDED_SSL 是某些负载均衡器（如 AWS ALB）用的字段，比 X-Forwarded-Proto 更早出现，建议一起兜底。
用在 redirect() 或 base_url() 前必须校验
很多人在构造跳转链接或生成静态资源 URL 时直接拼 http://，结果混合内容（Mixed Content）被浏览器拦截。这时候靠 is_https() 不够，得用上面的 is_https_safe()。
性能影响几乎为零，但漏掉会导致前端报 Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure script 这类错误。
- 不要在 config.php 里静态写
$config['base_url'] = 'https://...';—— 开发环境会炸 - 在
base_url()调用前动态判断协议，或封装成secure_base_url() - redirect() 时若目标是站内路径，用
site_url()更稳妥；跨域跳转务必先is_https_safe()再拼 scheme
真正麻烦的从来不是函数怎么写，而是你不知道哪些中间件悄悄改了 $_SERVER，又不告诉你。每次换部署环境，都得重新 audit 这几个字段是否存在、值是否可信。