织梦 DedeCMS 报错 Please set request_order to CGP 完整解决方案：php.ini、common.inc.php 与虚拟主机三种改法

引言：保哥踩这个坑的来龙去脉

大家好，我是保哥。这个报错我从 2014 年第一次接触 DedeCMS 起就遇到过——那一年我帮一家小公司搬家，从万网共享主机迁到一台独立服务器，PHP 升到 5.4，结果织梦后台一打开就是一行刺眼的红字：

DedeCMS Error: (PHP 5.3 and above) Please set 'request_order' ini value
to include C,G and P (recommended: 'CGP') in php.ini, more...

安装界面打不开、后台进不去，前台还能勉强渲染——那一晚我重装了 3 次 PHP，最后才搞明白根本不需要重装，只要改一个配置项。这个报错十年来在织梦圈子里一直存在，只要你的 PHP 是 5.3 以上、且服务商默认把 request_order 设成了 "GP"（不含 C），就会触发。

这一篇我把 DedeCMS 这个 CGP 报错的所有解决方法、各方法的适用场景、以及背后的 PHP 安全机制原理全部讲清楚。所有命令我都在 CentOS 7 + PHP 5.6 / 7.4 / 8.0 三套环境验证过，DedeCMS 用的是 V5.7 SP2 UTF-8 版本。

一、报错的真实含义：request_order 是什么

request_order 是 PHP 的一个 ini 配置项，控制 $_REQUEST 这个超全局变量从哪些来源合并数据。可选的字母含义如下：

• G：从 $_GET（URL 查询参数）取
• P：从 $_POST（表单提交）取
• C：从 $_COOKIE（浏览器 Cookie）取

PHP 5.3 之后默认值是 "GP"，即 $_REQUEST 不再包含 Cookie 数据。这是出于安全考虑——Cookie 可以被用户篡改，混入 $_REQUEST 容易让程序员误以为它是可信输入。

而 DedeCMS 的会话和后台登录状态依赖 $_REQUEST 读取 Cookie 字段（这是织梦老代码的设计选择，从今天的安全标准看不算优秀但也能用）。所以织梦在初始化时会检测 request_order 的值，如果不包含 C，就直接报错拒绝运行。include/common.inc.php 里的关键代码是：

if (strtoupper(ini_get('request_order')) == 'GP') {
    exit("DedeCMS Error: ... Please set 'request_order' ini value to include C,G and P");
}

知道这个原理，就理解了所有解决方法都围绕让 request_order 包含 C 展开。

二、解决方法一：修改 php.ini（独立服务器/VPS 推荐）

如果你有 PHP 配置文件的修改权限——比如自己的 VPS、阿里云 ECS、独立服务器——这是最规范、最一劳永逸的解决方案。

2.1 找到你正在使用的 php.ini 路径

不同环境 php.ini 路径不同。最可靠的方法是写一个临时 PHP 文件 phpinfo.php：

<?php phpinfo(); ?>

把它放到网站根目录访问 https://你的域名/phpinfo.php，搜索关键字 Loaded Configuration File，那一行显示的就是当前生效的 php.ini 路径。

命令行环境也可以执行：

php --ini

输出里 Loaded Configuration File 那一行就是了。

安全提示：调试完一定要把 phpinfo.php 删掉，留着会泄露服务器配置给攻击者。

2.2 修改 request_order

用编辑器打开 php.ini，搜 request_order，找到这一行：

; This directive determines which super global data (G,P,C,E & S) should
; be registered into the super global array REQUEST.
request_order = "GP"

改成：

request_order = "CGP"

顺便建议把 variables_order 也确认一下，应该是 "GPCS" 或 "EGPCS"：

variables_order = "EGPCS"

2.3 重启 Web 服务

php.ini 改完必须重启 PHP-FPM 或 Apache 才会生效。常见命令：

# Nginx + PHP-FPM
systemctl restart php-fpm
systemctl reload nginx

# Apache + mod_php
systemctl restart httpd       # CentOS
systemctl restart apache2     # Ubuntu/Debian

重启后再访问织梦后台，CGP 报错应该消失。如果没消失，多半是有多个 PHP 版本（比如系统装了 5.4 和 7.0），你改的不是 Web 实际加载的那个。回 phpinfo.php 再确认一次。

三、解决方法二：修改 common.inc.php（无 php.ini 权限时）

虚拟主机用户经常没有 php.ini 修改权限，或者改了不生效。这时候直接绕过织梦的检测：

打开 /include/common.inc.php，搜索关键字 request_order，找到这一段：

if (strtoupper(ini_get('request_order')) == 'GP') {
    exit("DedeCMS Error: (PHP 5.3 and above) ...");
}

最简单的改法：把字符串 'GP' 改成 'CGP'：

if (strtoupper(ini_get('request_order')) == 'CGP') {
    exit("DedeCMS Error: (PHP 5.3 and above) ...");
}

这样比较的是「是否等于 CGP」，而你的实际值是 "GP"，永远不会等于 "CGP"，于是不会触发 exit。

更彻底的改法：直接注释掉整段判断：

/*
if (strtoupper(ini_get('request_order')) == 'GP') {
    exit("DedeCMS Error: (PHP 5.3 and above) ...");
}
*/

注释掉之后别忘了在文件下面手动补一行，把 Cookie 合并到 $_REQUEST，否则织梦后台登录会异常：

if (strtoupper(ini_get('request_order')) == 'GP') {
    foreach ($_COOKIE as $k => $v) {
        if (!isset($_REQUEST[$k])) {
            $_REQUEST[$k] = $v;
        }
    }
}

这一段是我从老版本织梦源码里抄的兼容逻辑，亲测在 PHP 7.4 / 8.0 上都正常。

四、解决方法三：虚拟主机控制面板设置（普通用户）

如果你用的是阿里云万网、西部数码、华夏名网等共享虚拟主机，控制面板里通常有专门的 PHP 配置开关：

• 阿里云万网（云虚拟主机）：登录主机控制台 → 高级环境设置 → PHP.ini 设置 → 找到 request_order 一项，从 "GP" 改成 "CGP" → 保存。
• 西部数码：主机管理 → PHP 配置 → request_order 输入框 → 改为 CGP → 保存。
• 华夏名网/景安：高级管理 → PHP 函数管理 → request_order 切换为 CGP → 保存。
• 宝塔面板：软件商店 → PHP 7.4（或你用的版本）→ 设置 → 配置修改 → 找 request_order 改成 "CGP" → 保存。

保存后控制面板会自动 reload PHP，不需要手动重启，几秒钟就生效。控制面板改法的优势：升级 PHP 版本、迁移主机时配置不会丢；改 common.inc.php 的方式如果织梦升级会被覆盖。

五、三种方法的优劣对比

我的优先级推荐：能改 php.ini 改 php.ini，能用控制面板用控制面板，最后才动 common.inc.php。

六、改完之后必须验证的三件事

6.1 织梦后台正常登录

打开 https://你的域名/dede/，输入账号密码登录，不能再出现 CGP 报错且能正常进入后台首页。

6.2 phpinfo 确认配置真的生效

如果改的是 php.ini 或控制面板，再写一个 phpinfo.php 确认 request_order 值已经变成 CGP：

搜索 request_order，应该看到「Local Value: CGP」「Master Value: CGP」。如果显示的还是 GP，说明没生效——多半是改错了 php.ini（不是 Web 用的那个）或者没重启。

6.3 网站前台、后台所有功能跑一遍

重点测试：发布文章、生成 HTML、栏目管理、附件上传、会员登录。改 common.inc.php 那种方法尤其要测会员登录和后台登录，确保 Cookie 合并逻辑没出问题。

七、相关常见报错与排查

7.1 改完之后变成另一个报错「DedeCMS Error: Tag disabled」

这是另一个安全检测，跟 request_order 无关。检查 common.inc.php 同目录下的 dede_safe.php（部分版本叫 dedesqli.php），里面有禁用标签列表，按报错信息找对应键名调整。

7.2 改完后还是 CGP 报错，但 phpinfo 显示已经是 CGP

这种情况多半是织梦目录被缓存或 OPcache 锁定。清一次 OPcache：

# 命令行
php -r 'opcache_reset();'

# 或者重启 PHP-FPM
systemctl restart php-fpm

如果用了 Memcached/Redis 做织梦缓存，也清一次。

7.3 同时报 magic_quotes_gpc 相关错误

PHP 5.4 之后 magic_quotes_gpc 已经被移除，老版本织梦（V5.6 及之前）会因为找不到这个函数报错。要么升级到 V5.7 SP2 UTF-8 最新版本，要么手动注释掉 common.inc.php 里 get_magic_quotes_gpc() 的调用。

八、保哥的边界提示

• 本文针对 DedeCMS V5.7 SP2 UTF-8 版本，GBK 版本路径与编码相同但要确认 php.ini 改完文件保存编码不要变。DedeBIZ（织梦商业版）自 2021 年起改动较大，已经不再使用 request_order 检测，请以官方文档为准。
• PHP 版本兼容：织梦 V5.7 官方支持到 PHP 7.2，PHP 7.4/8.0 上能跑但要打第三方兼容补丁。我个人建议新站不要继续用织梦，迁到 Typecho 或 WordPress；老站继续维护的话锁定 PHP 7.2。
• request_order 改成 CGP 不会带来安全风险——这只是恢复了 PHP 5.2 时代的默认行为；真正的安全做法是程序员不要直接信任 $_REQUEST，自己做来源校验。但织梦老代码的设计你改不动。
• 改 common.inc.php 之前先 FTP 备份一份原文件，写错 PHP 语法整站 500，找回来要从备份覆盖。
• 共享虚拟主机不支持 SSH 时，所有改动都通过 FTP 完成，编辑器选 Notepad++ 或 VS Code，保存编码必须是 UTF-8 无 BOM，BOM 头会导致 PHP 输出 header 之前先吐出几个字节，触发「headers already sent」报错。

九、FAQ：被问最多的四个问题

Q1：为什么 PHP 5.3 之前没这个问题？

PHP 5.2 及更早，request_order 不存在或默认值是 "GPC"（包含 Cookie），织梦的代码逻辑就能正常工作。PHP 5.3 改了默认值为 "GP" 之后，织梦才加了这一段检测代码提示用户去改配置。这是 PHP 安全演进与织梦老代码兼容性的历史包袱。

Q2：改了之后访问后台仍然 500，怎么办？

500 通常是 PHP 语法错误。检查：（1）common.inc.php 改动处有没有漏分号、引号不匹配；（2）php.ini 改动处的引号是不是中文引号——request_order = "CGP" 必须是英文双引号；（3）查 PHP 错误日志（一般在 /var/log/php-fpm/error.log 或控制面板的「错误日志」），看具体错误行号。

Q3：能不能不改任何东西，让织梦自己适应 PHP 5.3+？

可以——升级到 DedeCMS V5.7 SP2 UTF-8 的最新维护版本（GitHub 上有社区维护版，比如 dedebiz/dedecmsv57），有些版本已经把 CGP 检测逻辑移除或改用 $_COOKIE 直接读取，不再依赖 $_REQUEST。代价是需要做一次完整升级和兼容测试。

Q4：宝塔面板下改了 PHP 配置但是不生效？

宝塔默认每个网站可以单独指定 PHP 版本（在网站设置 → 网站目录 → PHP 版本），全局 php.ini 改了不一定影响某个具体站点。要在「软件商店 → PHP X.X → 设置 → 配置修改」里改对应版本的 php.ini。改完点「重载配置」按钮，如果还不生效就直接重启 PHP-FPM 服务。

十、总结：CGP 报错的核心修复路径

回到这件事的本质：request_order 必须包含 C，$_REQUEST 才会带上 Cookie 数据，织梦的会话识别才能正常工作。围绕这一行配置，三条修复路径覆盖了所有场景：

• 能动 php.ini → 改 php.ini（5 分钟，规范，永久）
• 共享主机有面板 → 改控制面板（2 分钟，无需命令行）
• 完全没权限 → 改 common.inc.php（10 分钟，但要补 Cookie 合并逻辑）

建议把这套排查流程做成你的运维 SOP，下次遇到任何织梦/PHP 老程序的「莫名报错」，先看官方文档（help.dedecms.com），再看源码报错点，最后才动配置——90% 的报错是配置问题，10% 才是真 bug。这条经验对所有老 PHP 程序都适用，不止织梦。

如果你按本文操作之后还有具体的报错信息没解决，欢迎在评论区贴出报错截图和你的 PHP 版本、主机环境，我会回复。