PHP后端不会因移动端访问返回404，根本原因在于路由、重写规则、请求路径或前端跳转逻辑问题；404由服务器根据$_SERVER['REQUEST_URI']匹配结果决定，与User-Agent无关。
PHP 后端本身不会因为“移动端访问”就返回 404，真正出问题的通常是路由、重写规则、请求路径或前端跳转逻辑——404 是 HTTP 状态码，由服务器根据 $_SERVER['REQUEST_URI'] 匹配到的脚本是否存在/可执行来决定，和 User-Agent 无关。
Apache / Nginx 的重写规则漏掉了移动端路径
很多项目用伪静态（如 ThinkPHP/Laravel 的 index.php 入口模式），但 .htaccess 或 nginx.conf 只写了 PC 端的 rewrite，没覆盖 H5 或小程序的请求路径（比如带 /m/、/api/mobile/ 或无后缀的 JSON 接口）。
常见表现：
– PC 浏览器访问 /user/info 正常，手机浏览器或 WebView 访问同一地址却 404
– 小程序调用 https://api.example.com/v1/profile 返回 404，但 cURL 模拟 PC UA 却成功
- 检查 Apache 的
.htaccess是否包含类似RewriteRule ^(.*)$ index.php [L]，且该规则作用于所有子路径（包括/m/） - Nginx 需确认
location /块里有try_files $uri $uri/ /index.php?$query_string;，而不是只写location ~ \.php$ - 若用了二级目录部署（如
https://example.com/m/），确保DocumentRoot或alias指向正确，并在子目录下也放了入口文件或配置了独立 rewrite
$_SERVER['REQUEST_URI'] 被前端或 CDN 二次修改
某些 SPA 框架（Vue Router history 模式）、CDN（如 Cloudflare 的「Always Online」或路径重写规则）、或反向代理（Nginx proxy_pass）会改写原始 URI，导致 PHP 收到的路径和真实请求不一致，require 或 include 找不到对应文件。
立即学习“PHP免费学习笔记（深入）”；
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
验证方法：在入口文件开头加一行
error_log('URI: ' . $_SERVER['REQUEST_URI'], 4);
然后用手机访问并查看 error.log。如果日志里出现异常路径（如多出 //、含未解码的 %2F、或被截断），就是中间层改写了 URI。
- CDN 层：关闭「自动重写」或「优化路径」类功能；Cloudflare 中检查 Page Rules 是否误匹配了移动端 UA 并触发了重定向
- Nginx proxy_pass：确保没有用
rewrite指令隐式修改了$request_uri，建议用proxy_set_header X-Original-URI $request_uri;辅助排查 - 前端 History 模式：确保服务端对所有非静态资源请求都 fallback 到
index.php，不能只 fallback/
移动端特有路径未注册路由（框架场景）
使用 Laravel、ThinkPHP、CodeIgniter 等框架时，如果为移动端单独定义了路由组（如 Route::domain('m.example.com') 或 Route::prefix('mobile')），但没启用对应中间件、或控制器命名空间错误、或控制器文件未按 PSR-4 规则放置，就会 404。
典型错误：
- Laravel 中写了
Route::prefix('m')->group(...)，但控制器类名是MobileController，而实际文件是app/Http/Controllers/Mobile.php（缺少命名空间或类名不匹配） - ThinkPHP6 的多应用模式下，
route/app/m/下的路由文件未被加载，因config/route.php中没开启'm' => true - CI3 的
application/routes.php里写了$route['m/(:any)'] = 'mobile/$1';，但controllers/mobile/目录下没有对应控制器类，或类未继承CI_Controller
移动端 404 最容易被忽略的点：不是 UA 判断失效，而是你根本没让服务器“看到”那个请求路径——它可能在到达 PHP 之前就被 Web 服务器丢弃、被 CDN 重定向、或被前端 router 拦截后发了个不存在的 URL。先抓包看真实请求地址，再查日志看 PHP 收到了什么，比猜 UA 更有效。
