
如何在 Nginx 配置中禁止上传特定文件类型
宝塔面板本身不直接提供「上传白名单」功能,真正起作用的是 Nginx 的 location 规则和 deny 指令。关键不是“限制用户选什么”,而是“拒绝服务器处理危险后缀的上传请求”。
常见错误是只改 PHP 的 upload_max_filesize 或宝塔的「PHP 设置」,这只能限制大小,对 .php、.jsp、.sh 等可执行文件毫无防御力。
• 在站点配置中找到 location ~ \.php$ 或 location ~ ^/uploads/ 这类上传目录的区块
• 在该区块内添加:if ($request_filename ~ \.(php|phtml|php3|php4|php5|phar|pl|py|jsp|asp|aspx|sh|exe|bat)$) { return 403; }
• 注意:不能放在 location / 根路径下,否则会误杀静态资源;必须精准匹配上传接口或上传目录
• 修改后务必执行 nginx -t 检查语法,再 systemctl reload nginx(或在宝塔界面点「重载配置」)
为什么 upload
.php 接口仍可能绕过 Nginx 后缀限制
Nginx 只能按请求路径和文件名后缀拦截,但很多 CMS(如 WordPress、ThinkPHP)的上传逻辑是先存为临时随机名(如 tmp_abc123),再由 PHP rename 成目标名。此时 Nginx 看不到最终后缀,拦截失效。
• 必须配合 PHP 层校验:检查 $_FILES['file']['name'] 的真实扩展名,而非仅依赖 $_FILES['file']['type'](后者可伪造)
• 禁用 move_uploaded_file() 对危险后缀的写入,例如用 pathinfo($filename, PATHINFO_EXTENSION) 提取后缀并比对白名单
• 上传目录设置为不可执行:在宝塔「网站根目录」右侧点击「设置」→「网站目录」→ 勾选「禁止访问 .php 文件」,这会自动在该目录下生成带 deny all; 的子配置
宝塔后台能配但容易被忽略的安全开关
宝塔 8.x+ 版本在「网站」→「设置」→「防篡改」和「PHP 管理」里藏了几个关键选项,不开等于裸奔。
• 「防篡改」页中启用「防止网站被上传木马」:它会在站点配置中自动插入针对 /wp-content/、/uploads/、/public/ 等常见上传路径的 location 规则,但不会覆盖你手动写的规则
• 「PHP 管理」→「禁用函数」中确认已禁用 eval、assert、system、exec、shell_exec、passthru —— 即使木马上传成功,也难执行命令
• 「网站目录」页中关闭「开启防跨站攻击(open_basedir)」反而更危险:应保持开启,并确保其值包含当前网站路径(如 /www/wwwroot/your-site/:/tmp/:/proc/)
上传路径配置错误导致 403 或 500 的典型表现
加了限制后出现异常,往往不是规则写错,而是 location 匹配顺序或 root 路径冲突。
• 现象:上传图片返回 403,但图片实际已写入服务器 → 检查是否在 location ~ \.php$ 外又写了另一个 location ^~ /uploads/,且里面漏了 try_files $uri @php; 导致 PHP 不接管
• 现象:所有请求变 500 → 检查 if 是否写在了 server 块顶层(Nginx 官方明确不推荐),应始终嵌套在 location 内
• 现象:限制对 POST /upload.php 生效,但对 GET /uploads/shell.php 不生效 → 因为 GET 请求走的是静态文件逻辑,需单独加 location ~ ^/uploads/.*\.(php|jsp|sh)$ { deny all; }
Nginx 的上传类型限制本质是路径 + 后缀双控,而 PHP 层的真实扩展名校验才是最后一道防线。很多人只做前者,却忘了上传后的文件只要没被解析执行就只是普通文本——所以 deny all 和 open_basedir 的组合比单纯拦后缀更可靠。
Nginx 只能按请求路径和文件名后缀拦截,但很多 CMS(如 WordPress、ThinkPHP)的上传逻辑是先存为临时随机名(如 tmp_abc123),再由 PHP rename 成目标名。此时 Nginx 看不到最终后缀,拦截失效。
• 必须配合 PHP 层校验:检查 $_FILES['file']['name'] 的真实扩展名,而非仅依赖 $_FILES['file']['type'](后者可伪造)
• 禁用 move_uploaded_file() 对危险后缀的写入,例如用 pathinfo($filename, PATHINFO_EXTENSION) 提取后缀并比对白名单
• 上传目录设置为不可执行:在宝塔「网站根目录」右侧点击「设置」→「网站目录」→ 勾选「禁止访问 .php 文件」,这会自动在该目录下生成带 deny all; 的子配置
宝塔后台能配但容易被忽略的安全开关
宝塔 8.x+ 版本在「网站」→「设置」→「防篡改」和「PHP 管理」里藏了几个关键选项,不开等于裸奔。
• 「防篡改」页中启用「防止网站被上传木马」:它会在站点配置中自动插入针对 /wp-content/、/uploads/、/public/ 等常见上传路径的 location 规则,但不会覆盖你手动写的规则
• 「PHP 管理」→「禁用函数」中确认已禁用 eval、assert、system、exec、shell_exec、passthru —— 即使木马上传成功,也难执行命令
• 「网站目录」页中关闭「开启防跨站攻击(open_basedir)」反而更危险:应保持开启,并确保其值包含当前网站路径(如 /www/wwwroot/your-site/:/tmp/:/proc/)
上传路径配置错误导致 403 或 500 的典型表现
加了限制后出现异常,往往不是规则写错,而是 location 匹配顺序或 root 路径冲突。
• 现象:上传图片返回 403,但图片实际已写入服务器 → 检查是否在 location ~ \.php$ 外又写了另一个 location ^~ /uploads/,且里面漏了 try_files $uri @php; 导致 PHP 不接管
• 现象:所有请求变 500 → 检查 if 是否写在了 server 块顶层(Nginx 官方明确不推荐),应始终嵌套在 location 内
• 现象:限制对 POST /upload.php 生效,但对 GET /uploads/shell.php 不生效 → 因为 GET 请求走的是静态文件逻辑,需单独加 location ~ ^/uploads/.*\.(php|jsp|sh)$ { deny all; }
Nginx 的上传类型限制本质是路径 + 后缀双控,而 PHP 层的真实扩展名校验才是最后一道防线。很多人只做前者,却忘了上传后的文件只要没被解析执行就只是普通文本——所以 deny all 和 open_basedir 的组合比单纯拦后缀更可靠。