phpEnv 的 Nginx 模式实为封装假代理，手动修改 nginx.conf 会被覆盖；应改用其可配置的 Apache，通过 mod_proxy 实现反向代理与 history 模式支持，并需显式配置 CORS 头及 cookie 路径适配。
phpEnv 本身不支持 Nginx 反向代理配置，它默认只配 Apache；直接在 phpEnv 里改 Nginx 配置文件无效，因为 phpEnv 启动的不是你手动编译或系统安装的 Nginx，而是它封装的轻量级服务容器。
phpEnv 的 Nginx 实际运行机制
phpEnv 是 Windows 下的集成环境（类似 XAMPP），底层用的是精简版 Nginx + PHP-FPM 封装逻辑。它的“Nginx”只是启动脚本调用的一个预编译二进制，配置由 phpEnv 自己生成并管理，nginx.conf 文件即使你手动修改，重启 phpEnv 后也会被覆盖回默认值。
常见错误现象：
- 你在
C:\phpEnv\nginx\conf\nginx.conf里加了location /api/代理规则，重启后完全不生效 - 浏览器访问
http://localhost/api/login仍返回 404，而不是转发到后端 - 控制台看到请求发到了 phpEnv 的 Apache 默认端口（如 8080），而非你期望的代理目标
根本原因：phpEnv 的“Nginx 模式”实际是假的——它只是把 Nginx 当作静态资源服务器用，所有动态请求（包括 /api/）默认全部交给内置 Apache 处理，压根没走你写的 proxy_pass。
立即学习“PHP免费学习笔记（深入）”；
真正能用的替代方案：绕过 phpEnv 的 Nginx，改用其 Apache 做反向代理
phpEnv 的 Apache 是真实可配置、且不会被覆盖的。你可以用 mod_proxy 在 Apache 中实现等效的反向代理，效果和 Nginx 一样，还能绕过 phpEnv 对 Nginx 的限制。
操作步骤：
- 确保 phpEnv 中 Apache 已启用
mod_proxy和mod_proxy_http（默认已开，检查C:\phpEnv\apache\conf\httpd.conf中有无LoadModule proxy_module modules/mod_proxy.so） - 在
C:\phpEnv\apache\conf\extra\httpd-vhosts.conf里添加虚拟主机配置：
ProxyRequests Off
<Proxy *>
Require all granted
</Proxy><p><VirtualHost *:80>
ServerName localhost
DocumentRoot "C:/phpEnv/www/dist"</p><pre class='brush:php;toolbar:false;'># 前端静态资源
<Directory "C:/phpEnv/www/dist">
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.html [L]
</Directory>
# API 代理（关键）
ProxyPass "/api/" "http://127.0.0.1:8080/"
ProxyPassReverse "/api/" "http://127.0.0.1:8080/"
ProxyPreserveHost On</VirtualHost>
- 把前端打包后的
dist放到C:\phpEnv\www\dist，后端服务确保运行在http://127.0.0.1:8080 - 重启 phpEnv 的 Apache（不是 Nginx）
为什么不能用 phpEnv 的“Nginx 模式”跑 Vue/React 前端？
因为 phpEnv 的 Nginx 不支持 try_files 的完整语义，尤其对 Vue Router 的 history 模式会失败。你写 try_files $uri $uri/ /index.html;，它可能只认 $uri，遇到 /user/123 这种路径就直接 404，根本不会 fallback 到 index.html。
而 Apache 的 RewriteRule 在 phpEnv 中是稳定可用的，上面配置里的重写逻辑就是专为 history 模式设计的。
性能与兼容性影响：
- Apache 代理比 Nginx 略重，但本地开发完全无感知
- 所有 cookie、header、HTTPS（若需）都能透传，
ProxyPreserveHost On是关键 - 若后端接口路径含
/api/api/v1/xxx，注意ProxyPass末尾的/：去掉它会导致多一层/api前缀被保留
跨域问题在 phpEnv 下最容易被忽略的一点
很多人以为只要代理通了就万事大吉，结果登录时 token 不带、验证码图片 404、或者 withCredentials: true 的请求被静默丢弃——这是因为 phpEnv 的 Apache 默认不设置 CORS 头，而浏览器对带凭证的跨域请求（哪怕已代理）仍会校验响应头。
必须在 Apache 虚拟主机配置中显式加 CORS 响应头：
Header always set Access-Control-Allow-Origin "http://localhost"
Header always set Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS"
Header always set Access-Control-Allow-Headers "Content-Type,Authorization"
Header always set Access-Control-Allow-Credentials "true"
# OPTIONS 预检处理
RewriteCond %{REQUEST_METHOD} =OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]别漏掉 mod_headers 模块的启用，否则 Header 指令无效。
最麻烦的其实是 cookie path：若后端返回的 Set-Cookie 中 Path=/prod-api/，前端在 http://localhost/ 下无法读取。这时得加 ProxyCookiePath /prod-api /，但 phpEnv 的 Apache 版本较老，该指令可能不支持——更稳的办法是让后端把 cookie path 设为 /，或前端用 axios.defaults.withCredentials = true 配合域名统一。
