PHP应用HTTPS下返回404通常源于Web服务器配置错误：Apache需检查RewriteCond对HTTPS的判断、RewriteBase设置及-f/-d文件检测；Nginx需确认location在443 server块内、fastcgi_param SCRIPT_FILENAME路径正确、透传HTTPS参数；框架需强制URL为HTTPS并正确识别X-Forwarded-Proto。
PHP 应用在 HTTPS 下返回 404，通常不是 PHP 本身的问题，而是 Web 服务器（Nginx/Apache）未正确将 HTTPS 请求路由到 PHP 处理器，或重写规则未适配 HTTPS 上下文。
Apache：.htaccess 里 RewriteRule 不匹配 HTTPS 请求
很多项目依赖 .htaccess 做前端控制器路由（如 Laravel、ThinkPHP），但默认规则常只处理 HTTP 的 REQUEST_URI，而 HTTPS 请求中某些环境变量（如 %{HTTPS} 或 %{SERVER_PORT}）未被显式判断，导致重写失效，最终返回 404。
- 检查是否漏加
RewriteCond %{HTTPS} off或相反条件，尤其当站点强制 HTTPS 后，mod_rewrite规则仍按 HTTP 路径匹配却没 fallback - 确保
RewriteBase正确：若部署在子目录（如https://example.com/app/），RewriteBase /app/必须存在且末尾带斜杠 - 避免用
%{REQUEST_FILENAME}判断静态文件是否存在——HTTPS 下某些 CGI 模式中该变量可能为空或路径不一致，改用-f/-d文件系统检测更可靠
Nginx：fastcgi_pass 指向错误或缺少 HTTPS 相关 header 透传
Nginx 本身不执行 PHP，靠 fastcgi_pass 转发给 PHP-FPM。HTTPS 404 很可能是请求根本没进 PHP，而是被 Nginx 直接返回了 404 —— 原因包括 location 匹配失败、root 路径错、或 PHP-FPM socket 地址不可达。
- 确认
location ~ \.php$块在 server { listen 443 ssl; ... } 内，而不是只写在 HTTP 的 server 块里 - 检查
fastcgi_param SCRIPT_FILENAME是否拼出真实物理路径，例如：fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;（推荐用$realpath_root避免符号链接解析问题） - 必须透传
HTTPS环境变量给 PHP，否则$_SERVER['HTTPS']为空，Laravel 等框架生成 URL 会降级为 http://：fastcgi_param HTTPS on;
PHP 框架内 URL 生成异常导致“伪 404”
浏览器地址栏显示 HTTPS，但点击链接跳转成 HTTP，再被服务器 301 重定向后丢失路径参数，最终 404 —— 这类现象看似是 HTTPS 配置问题，实则是 PHP 应用未感知当前为 HTTPS 环境。
立即学习“PHP免费学习笔记（深入）”；
- Laravel：确保
APP_URL=https://yourdomain.com，并在AppServiceProvider@boot中添加：if ($this->app->environment('production')) { \URL::forceScheme('https'); } - ThinkPHP：检查
app.php中'url_common_param' => false和'url_html_suffix'是否干扰路由匹配；同时确认$_SERVER['HTTPS'] === 'on'或$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https'被正确识别（反向代理场景常见） - 原生 PHP：不要直接拼
http://，用($_SERVER['HTTPS'] ?? '') === 'on' ? 'https://' : 'http://'判断，但注意负载均衡后端可能把 HTTPS 卸载，需依赖X-Forwarded-Proto
真正卡住的点往往不在 PHP 代码里，而在 Nginx/Apache 的 SSL 配置与 PHP 路由入口之间的衔接层。尤其当使用 CDN 或反向代理时，$_SERVER 变量的真实性需要手动校验，不能默认信任。
