phpEnv Nginx配置解决Shopify/Magento等大型CMS的Rewrite规则-php教程-PHP中文网

nginx需用try_files替代rewrite实现magento/shopify路由，静态路径须用^~前缀并置于php块之前，shopify proxy需透传$query_string，rewrite_log仅限调试且phpenv可能缺失realip模块。

phpenv nginx配置解决shopify/magento等大型cms的rewrite规则

phpEnv 是 Windows 下轻量级 PHP 开发环境，内置 Nginx（通常为 1.20+），但默认配置极简，**不自带 location 或 rewrite 规则适配 Shopify、Magento 这类依赖复杂路径重写的 CMS**。直接放 Magento 代码会 404，Shopify Proxy 端点无法解析 —— 根本原因不是 PHP 没跑起来，而是 Nginx 根本没把请求正确转发给 index.php。

Magento 2 的 rewrite 必须用 break，不能用 last

Magento 2 要求所有非静态资源都经由 index.php 入口统一处理，Nginx 需在匹配到 PHP 路径后立即终止规则链、交由 FastCGI 处理，而不是重新发起内部请求。

last 会让 Nginx 把重写后的 URI（如 /catalog/product/view/id/1 → /index.php/catalog/product/view/id/1）再走一遍 location 匹配，极易触发循环或 404
break 则直接停止 rewrite 执行，保留当前 URI 上下文，让后续的 try_files 或 fastcgi_pass 正常工作
典型错误配置：rewrite ^/(.*)$ /index.php/$1 last; —— 在 phpEnv 的默认 server 块里，这会导致无限内部重定向

正确写法（放在 location / 块内）：

location / {
    try_files $uri $uri/ /index.php?$query_string;
}

注意：这里没用 rewrite，而是靠 try_files 实现等效逻辑，更安全、更符合 phpEnv 的默认结构。

Shopify Proxy endpoint 必须捕获 query string 并透传

Shopify App 的 Proxy 请求形如 /apps/proxy?path=/admin/products.json，后端需读取 path 参数并转发。Nginx 若未显式携带 $query_string，PHP 就收不到原始参数。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

错误写法：rewrite ^/apps/proxy$ /index.php break; → $_GET['path'] 为空
正确写法：rewrite ^/apps/proxy$ /index.php?$query_string break;
若还涉及 header 透传（如 X-Shopify-Shop-Domain），需额外加 proxy_set_header，但 phpEnv 默认不启 proxy_pass，所以实际应走 FastCGI，此时 header 由 PHP 自己读 $_SERVER 变量，无需 Nginx 干预

静态资源和 PHP 路径必须分离，否则 rewrite 冲突

phpEnv 的默认配置常把所有 .php 文件塞进一个 location ~ \.php$ 块，但 Magento/Shopify 的路由规则（如 /media/、/static/）也落在 location / 下 —— 如果没优先级控制，Nginx 会先匹配正则 location ~ \.php$，导致 /static/adminhtml/.../style.css 被当成 PHP 执行而报错。

必须把静态路径声明为前缀匹配（^~），且放在 location ~ \.php$ 之前
例如 Magento 的静态资源目录：location ^~ /static/ { } 和 location ^~ /media/ { }
Shopify App 的前端资源（如 /assets/）同理，加 location ^~ /assets/ { } 并配 alias 或 root

顺序错了，^~ 就失效 —— Nginx 不会警告，只会静默走错分支。

rewrite_log on 只用于调试，上线必须关

phpEnv 默认关闭重写日志，但排查时可临时开启：rewrite_log on;（需配合 error_log ... notice;）。不过要注意：

该指令只能出现在 http 或 server 块，不能写在 location 里
开启后每条 rewrite 匹配都会打到 error.log，高并发下 I/O 暴涨，phpEnv 这种单机环境容易卡死
真正要确认 rewrite 是否生效，最可靠的是看 access.log 中的 $request_uri 和 $uri 差异，而非依赖 rewrite_log

很多开发者卡在“规则写了但没反应”，其实是没意识到 phpEnv 的 Nginx 编译时没启用 --with-http_realip_module，导致 $remote_addr 总是 127.0.0.1，if 判断失效 —— 这类底层限制，比 rewrite 语法本身更难察觉。