在网站开发过程中遇到上传图片等文件的功能，需要在服务器上设置该目录可写入，并且必须防止被上传 .php 等可执行的脚本文件。

根据文件所有者的不同，我们分两种情况讨论：

一、程序上传的用户与执行 PHP 的用户不同（例如程序代码通过 SSH 上传（root 用户），而 PHP 以 www 身份运行）

由于 Linux 上的文件默认权限是 644，目录默认权限是 755，所以在这种情况下，PHP 不能修改 root 上传的程序文件，也不能将客户端上传的图片文件保存到服务器上。

例如我们将客户端上传的文件指定到 /upload/ 目录，那么，

第 1 步，赋予它写入权限：

chmod 777 upload

递归所有子目录请加 -R 参数，但会将文件也更改为 777，赋予了执行权限，这是不建议的。文件若需写入权限请设为 666。

第 2 步，设置该目录下不允许执行 PHP：

我们无法保证客户端上传完全符合我们要求的文件，那么必须禁止任何文件的执行权限。（此处指 PHP 的执行权限，注意与 sh 执行权限的区别，后者由 chmod 命令修改）

nginx 的 .conf 文件配置示例：

location ~ /upload/.*\.(php|php5)?$
{
    deny all;
}

Apache 的 .htaccess 文件配置示例：

RewriteRule upload/(.*).(php)$ – [F]

特别注意：上面的代码必须加在 PHP 引用配置的上方才有效（如 nginx 的 PHP 引用配置 include enable-php-**.conf;）

默认 Linux 系统是大小写敏感的，所以规则中的正则表达式无须忽略大小写（但必须与实际的目录或文件名大小写一致），因为 MIME 类型中设置的是小写的 .php，那么类似大写的 .PHP 文件是不被 php-fpm 解释的，结果是被当作普通文本返回到客户端。

提问：有些目录需要设置为可写入，但里面还有正常的 php 文件，禁止执行会有问题吗？（例如 Discuz! 的 config 目录，ThinkPHP 的 Runtime 目录）

解答：以 Discuz! 为例，config 下面虽然有 config_*.php 等配置文件，但这些文件并非直接供客户端浏览，而是被其它 .php 文件引用（include 方式、IO 方式等），当 config 目录禁止执行 PHP 后并不会对它们造成影响。

我们在开发程序的过程中应避免在允许写入的目录下放置直接供客户端浏览的 .php 文件。

二、程序上传的用户与执行 PHP 的用户相同（例如程序代码通过 FTP 上传，且和 PHP 一样，都使用 www 用户）

常见于虚拟空间。这种情况下，通过 PHP 上传的文件可以保存到该网站下面的任何目录下（甚至是网站目录之外，即传说中的跨站），原因大家都懂，默认 755 中第一个是“7”，即所有者拥有写入权限。

因此，除了做到上述设置，我们必须严格控制客户端上传文件的保存路径，做到以下几点：

必须更改客户端上传的文件名，而非直接使用原文件名；

不得从客户端文件名获取扩展名，或者只控制允许的后缀名。

最可靠的文件类型判别方式是分析文件签名，参考：文件签名表，以防篡改后缀名欺骗。

举个早期的栗子：上传文件名为 abc.asp;.jpg，未改文件名保存到服务器，浏览器直接访问该文件，IIS 6 当作 abc.asp 来解析。

xoyozo 9 年前

13,327

服务器被攻击或出现异常警告的优化处理方式汇总（含 Discuz!）

本文不定时更新！

A： MySQL 执行 SHOW FULL PROCESSLIST

Q：查看连接数和慢查询，适用于 MySQL 数据库无法连接 1040

A： iftop -i eth0

Q：查看占用带宽的IP（命令：iftop -i eth0 -F ip/24），添加到安全组、防火墙、宝塔的黑名单中。

命令 grep -l "x.x.x.x" /www/wwwlogs/*.log 可以在 wwwlogs 目录下的所有 .log 文件中查找指定的恶意 IP。

A： goaccess -f xxx.log

Q：实时分析网站日志，查看请求最多的IP

A： net.xoyozo.weblog 日志分析工具

Q：自制的 Web 日志分析工具，可按多种方式排序，纠出可疑访问

A：重启 web 服务器

Q：有时候能解决 CPU 和内存消耗的问题，如果一会儿又升高，则需要找另外的原因

Q： 500 服务器内部错误

502 Bad Gateway

504 Gateway Time-out

A：查看 php 日志，可能的路径：

/usr/local/php/var/log/php-fpm.log

/www/server/php/[版本]/var/log/php-fpm.log

Q： RDS MySQL IOPS 使用率高的原因和处理

A：根据时间点查看慢查询

Q： Discuz! 论坛界面错乱、表情不显示、模块缺失、登录失败、发帖失败等等

A：进入管理中心 - 工具 - 更新缓存，能解决大部分问题

Q： Discuz! 浏览帖子提示“没有找到帖子”

A：进入数据库，修复表 pre_forum_post 或分表

Q： CPU 100% 或内存 100%，负载100+

A：原因有很多，以下是一些建议：

Windows 在任务管理器中查看进程

当前是否有正常的大流量访问（譬如民生类论坛的某个帖子突然火了）特别是重启无效的情况

对比网站日志大小可大致确定哪个网站被大量恶意请求。

观察：命令 top

排查：通过关闭网站来确定是某网站的问题，通过关闭功能确定是某功能的问题，如果 nginx 崩溃请参下条

案例：通过修改 mobcent 文件夹名确定是安米的文件被疯狂请求导致的，更新插件和 mobcent 包解决问题。

如果都是正常访问，top 看到很多 php-fpm，而且个个占用 CPU 还不小，那么根据服务器硬件配置来修改 php 的并发量，如宝塔面板在 php 设置 - 性能调整页，300 并发方案的推荐配置是：

max_children：300
start_servers：30
min_spare_servers：30
max_spare_servers：180

另外，memcached 或 redis 的配置也可以进行相应的修改。

另一个案例是 kswapd0 进程占满 CPU，原因是内存不足导致 swap 分区与内存频繁交换数据。同样调整 php 的设置即可。

也可以通过 iftop 来查询占用带宽较多的 IP 并封禁（出方向），如果 CPU 能降下来，那这个 IP 就是罪魁祸首。

* 使用 WAF 的审计 WAF 日志，未使用 WAF 的审计 Web 日志。

Q：阿里云 ECS 的 CPU 突然达到 100%，并持续到次日 0:00 左右

A：可能 ECS 是 t5 规格，受 CPU 积分制度限制，积分耗尽时 CPU 不工作。解决方法是更换其它规格产品或升配。

Q： ASP.NET 所在服务器 CPU 突然达到 50% 或 100%，并持续

A：首先确定哪个网站，再依次排查网站各功能。可能是 HttpWebRequest 请求远程数据时长时间未返回结果导致的程序阻塞。

Q： nginx 服务停止

A：查看 nginx 日志

WDCP 路径：/www/wdlinux/nginx-1.0.15/logs/error.log

Q：公网出带宽 100%，其它指标正常

A： Windows 在任务管理器-性能-资源监视器-网络查看占用带宽的进程PID，然后在任务管理器-详细信息中的找到对应的用户（如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽）；如果是被 PID 为 4 的 System 占用大部分带宽，也可以尝试重启 IIS 来解决。

CentOS 使用 nethogs 查看占用带宽的进程PID和USER，如果为每个网站分别创建了用户，就能知道是哪个网站占用了带宽，否则只能一个个关闭网站来判断，不知道大家有没有好的方法？当然还可以直接用 iftop 命令查看占用带宽的 IP。另外，查看每个网站在那个时间段的日志文件的大小也能大概看出是哪个网站被采集了。

A： Linux 显示每个用户会话的登入和登出信息

utmpdump /var/log/wtmp

参考：http://www.tulaoshi.com/n/20160331/2050641.html

Q： RDS 的 CPU 100%

A：如果是突然持续占满（同时伴随 ECS 资源使用率下降，页面出现 502），很大可能是受攻击（或社交网站推送突发事件等），查看“慢查询”，添加相关索引；如果是 Discuz! 论坛，可尝试修复优化表 pre_common_session。

如果是数日缓步上升，或新项目上线，考虑 SQL 慢查询，思路：MySQL / SQL Server。

MySQL：SHOW FULL PROCESSLIST

SQL Server：sp_who

Q： php 网站的服务器，内存在数天内缓慢上升

A：大概是 php-fpm 占用过多，或进程数太多

更改 php 的配置（如 max_spare_servers），执行：service php-fpm reload

Q：进程 cloudfs 占用内存过多

A：参：https://xoyozo.net/Blog/Details/cloudfs-cache

Q： RDS 磁盘占用过大

A：参：https://xoyozo.net/Blog/Details/how-to-use-rds

Q： ECS 受到 DDoS 攻击怎么办？

A：参：https://xoyozo.net/Blog/Details/aliyun-ddos-without-bgp

Q：如果 ECS 和 RDS 各项指标都没有异常，但网页打开慢或打不开502，TTFB 时间很长，是什么原因？（ECS 的 CPU 100%，RDS 的连接数上升，也可参考此条）

A：数据库有坏表，尝试优化/修复表（慢 SQL 日志中锁等待时间较长的表？），或主备切换。show full processlist 时看到许多

DELETE FROM pre_common_session WHERE sid='******' OR lastactivity<****** OR (uid='0' AND ip1='*' AND ip2='*' AND ip3='*' AND ip4='*' AND lastactivity>******)

Q： Discuz! 创始人(站长)密码被改

A：数据库找到 pre_ucenter_members 表，复制其它的已知登录密码的账号，复制其 password 和 salt 两个字段的值到创始人账号中，创始人账号即可用该密码登录了。

Q：通过 iftop 观察到，Discuz! 网站从 RDS 数据库到 ECS 网站服务器私网流量非常大，远大于公网流量

A：可能是缓存出问题了，尝试卸载重装 Redis 来解决。

Q：宝塔面板中安装的 Redis 经常自动停止

A：尝试卸载重装 Redis 来解决。

Q：马甲客户端出现“您的网络有些问题”

A：原因有许多，其中一个就是新建了一个数据表，然后 /source/class/table/ 下面丢失了对应的文件，具体可以找官方排查原因。

Q：排查服务器安全需要检查哪些日志？

A： Web日志、登录日志（/var/log/secure）等。

Q：带宽波形以几分钟为周期呈锯齿状波动是什么原因？

A：该现象主要由防火墙流量管控机制与检测周期设置共同作用所致。防火墙基于预设的带宽阈值执行安全防护策略，当检测到流量峰值超过设定阈值时，将自动触发限流策略拒绝后续请求。待流量回落至安全阈值后，系统自动恢复服务访问权限。若防火墙的带宽采样检测周期设置过长（如以分钟为单位的检测间隔），将导致系统对实时流量变化的响应出现迟滞。这种周期性的检测机制会使带宽监控数据在阈值临界点附近呈现规律性的锯齿状波动特征。

优化建议：可通过调整防火墙的流量检测周期至更小时间粒度（如10-15秒），或采用动态流量整形策略，以实现更平滑的带宽控制效果。

补充说明：对于阿里云监控数据的调用，建议注意接口调用频率管控。高频调用云监控API接口将触发阿里云的API计费策略，可能产生额外的资源消耗成本。

其它案例

某台 ECS 上的多个网站出现 502，查询到 CPU / 内存 / 带宽都比平时高，但都未满。用 iftop 看到连接的一个远程 Redis 占用内网带宽非常高。尝试重启远程 Redis 未果。尝试重启 ECS 上的 nginx 未果。尝试重启 ECS 未果。进入 ECS 的宝塔面板，重启 PHP 有效。
DDos攻击看这篇，现象是入流量大，CC攻击看这篇，现象是出流量大。

xoyozo 10 年前

10,839

记一次 Discuz! 论坛数据库崩溃“(1040) notconnect”CPU 和连接数 100% 的解决过程

论坛使用阿里云的 ECS + RDS + OSS 搭建，最近经常隔三差五出现 RDS 的 CPU 和连接数突然满负荷的情况，导致数据库无法连接。这种情况一般会认为是受到了攻击，因为如果是访问量大或者是哪里有慢查询，应该是资源消耗逐步上升直至崩溃的，沿着这个思路去查 Web 日志封 IP，但效果不大，关闭功能、卸载插件也没用。

开启阿里云后台的 SQL 审计，能看到 SQL 查询日志，但是很难找有问题的 SQL。

最终在重启 RDS 后执行以下语句列出所有正在执行或阻塞的语句：

show full processlist

在结果列中，Command 为 Query 是正在执行查询操作的语句，发现几乎所有的 SQL 都是：

SELECT * FROM pre_forum_thread WHERE tid>0 AND fid IN('42','95','247','41','567','62','149','229','37','230','93','190','284','75','38','568') AND `fid`<>'546' AND replies > 0 AND displayorder>=0 ORDER BY lastpost DESC  LIMIT 10

再加上之前出现的情况是，论坛帖子列表和详情页面能正常打开时，论坛首页也不一定能打开，所以基本定位到是“首页四格”的数据库查询导致的。

进入论坛后台首页四格设置，对比了版块 id 后确认了这个 bug。

单独执行该语句大约耗时 5s（主题帖 200 万），设置的缓存时间 10 分钟。

processlist 中看到这些语句的 state 都是 Creating sort index，尝试去掉 ORDER BY 后执行果然只需要 16ms。

5s 内的访客都是从数据库读取的，能处理完就正常，否则累积就导致 RDS 崩溃，每 10 分钟都会重现一次风险。

当然这个问题可以通过添加索引来解决。

xoyozo 10 年前

8,965

Discuz! X2 主题、帖子分表

对于大型站点，庞大的主题和帖子数据，分表放到一个主题表和一个帖子表中，已经成为影响性能的一个因素。因此，急需进行分表操作来避免 MySQL 对于大数据表的频繁操作。
1、后台分表
   Disucz! X2 后台重新调整了分表的机制，使得分表效率和后期站点性能得到提升。具体分表设置在后台 -> 站长 -> 主题分表（帖子分表）。
   1）主题分表
         主题分表分为两种类型，一种为主表，一种为存档表。主表只有一个，存档表可以有多个。我们进行分表操作，首先进行创建存档表的操作，然后进行主题移动，将指定条件的主题移动到存档表中。
         a、创建存档表
            打开 source/admincp/admincp_threadsplit.php 文件，找到创建存档表的条件分支

elseif($operation == 'addnewtable')

复制代码

            首先获取当前最大的主题表 id ，然后根据 forum_thread 的建表语句，生成新的存档表（id + 1），最后更新缓存。
      b、主题移动
            存档表建好后，下一步就是将主题移动到这个存档表中。在选择主题的时候，可以根据提供的搜索条件，特别是“更多选项”中的搜索条件，来转移符合条件的主题。这里主要是一个搜索的过程，转移数据的过程使用 REPLACE INTO … SELECT...FROM... 语句，比较简单。
   2）帖子分表
         帖子分表也是要分成两步，第一步先创建帖子分表，第二步转移数据。
         打开 source/admincp/admincp_postsplit.php 文件，找到帖子分表的条件分支

elseif($operation == 'split')

复制代码

如果是对主表进行分表操作，主表必须要大于400M，见下面的条件判断

if($status && ((!$tableid && $status['Data_length'] > 400 * 1048576) || ($tableid && $status['Data_length'])))

复制代码

在站长提交分表表单后，程序会先根据 getmaxposttableid 函数获取当前帖子表最大的 id ，然后根据已有的帖子表结构，创建新分表，并更新缓存等信息。创建成功后，开始转移数据的操作。找到条件分支

elseif($operation == 'movepost')

复制代码

，开始转移数据的操作。当从主表中转移数据时，是根据主题表中最后回复时间正序排列的主题 tid 来获取帖子数据的。

$query = DB::query("SELECT tid FROM ".DB::table($table)." WHERE posttableid='0' AND displayorder>='0' ORDER BY lastpost LIMIT 0, 1000");

复制代码

然后，利用 movedate 函数进行转移数据。
当从从表中转移数据时，是根据给定帖子表的 id，获取此表中first=1的帖子所属 tid，

$query = DB::query("SELECT tid FROM ".DB::table(getposttable($fromtableid))." WHERE `first`='1' LIMIT 0, 1000")

复制代码

然后利用 movedate 函数进行转移数据。
  在 movedate 函数中，根据获取到的 tid ，将属于此 tid 的帖子，利用 INSERT INTO … SELECT … FROM ...来转移数据。在此过程中，更新主题表中 posttableid 这个字段，来标识帖子的存储表。
2、主题列表页分表读取
   在主题列表页，只能看到主题主表中的主题。存档表中的主题都在存档区。
   在这部分的代码（source/module/forum/forum_forumdisplay.php）中，所有涉及到的主题表都以 $threadtable 这个变量代替，$threadtable 这个变量的获取，又是根据用户是否查看存档区的标识 archiveid 来判定。

$threadtable = $_G['gp_archiveid'] && in_array($_G['gp_archiveid'], $threadtableids) ? "forum_thread_{$_G['gp_archiveid']}" : 'forum_thread';

复制代码

当用户选择非存档内容时，archiveid = 0 或者不存在，这时，直接从 forum_thread 主表来读取主题列表。当用户选择存档内容时，archiveid = 1（1 表示存档表的 id，如果查看 id 为 2 的存档表，archiveid = 2），程序会根据 archiveid 来判断从哪个存档表中去获取主题列表。
3、帖子内容页分表读取
当用户浏览帖子内容页时，程序首先利用 loadforum 函数来获取当前的主题信息。在 loadforum 函数中，

$_G['thread'] = get_thread_by_tid($tid, '*', $addcondiction, $archiveid);

复制代码

根据提供的 tid，get_thread_by_tid 函数到主表和存档表中分表去查找，直到找到对应的主题信息。
在 source/module/forum/forum_viewthread.php 文件中，根据

$thread = & $_G['forum_thread'];

复制代码

$threadtable = $thread['threadtable'];
$posttableid = $thread['posttableid'];
$posttable = $thread['posttable'];

复制代码

这两句来判定该主题应该去哪个帖子表中去获取帖子内容列表。
4、发新主题
   发表新主题时，直接往主题主表中插入数据，对应的 posttableid = 0。然后，当插入帖子数据时，通过 insertpost 函数将数据插入帖子表中。
   在 insertpost 函数中，会先去判断所属主题的 posttableid 值，得到目标帖子表，然后再往该帖子表中插入帖子数据。
5、发新回复
   只有在主表的主题才能回复，因此，直接根据传递的tid去获取目标帖子表，然后插入数据。这个跟发新主题时，插入帖子内容过程相同。
6、编辑帖子
   同样，只有在主表中的主题的帖子才能被编辑，因此，主题都在 forum_thread 表中。需要获取的是该主题的帖子在哪个帖子表中。打开 source/include/post/post_editpost.php 文件，找到

$posttable = getposttablebytid($_G['tid']);

复制代码

程序在开始，通过这条语句来获取目标帖子表。在 getposttablebytid 函数中，程序根据 tid ，逐个主题表进行查找，找到对应的主题信息，获取目标帖子表，然后指向后续的编辑帖子操作。
8、取消存档
存在存档区的主题，如果想取消存档，可以通过页面底部的“取消存档”来执行。
打开 source/include/topicadmin/topicadmin_restore.php 文件，可以看到取消存档，实际上仅是将放在存档表中的主题移动到了主表中。同样，存档表的获取还是通过 archiveid 这个参数来决定的。

$threadtable = $archiveid ? "forum_thread_$archiveid" : 'forum_thread';

复制代码

从这可以看出，存档的概念仅限于主题，帖子无所谓存档的概念。

转自 beijing200808 16 年前

5,326

[已解决] Discuz! 后台用户管理中的用户表的主表和存档表什么意思啊？

wxy0510：经过用户表优化后，论坛不活跃用户将被转至存档表。这将意味着论坛在常规调用、查询都不会遍历这些存档表的数据。这也大大提高服务器工作效率，减少服务器负载。当然处于存档表的用户在执行一次登录操作后，数据会重新转入主表。

xoyozo：这个登录是指论坛本身的用户登录，如果用第三方客户端 App 登录一般是不起作用的（除非 App 考虑到了这个情况）

common_member 是主表，common_member_archive 是存档表，这两个表的用户数相加即为 UC 用户表 ucenter_members 中的用户总和。

转自 wxy0510 10 年前

12,190

Discuz! 分表笔记

准备：

先把超时时间改成 300 秒，参 http://www.cnblogs.com/jackluo/p/3366612.html

了解一下分表基本原理：http://www.discuz.net/thread-2132691-1-1.html

主题分表：
   可以任意创建主题存档表（forum_thread_X）
   使用“主题移动”功能，筛选符合条件的主题，移动到主题存档表
   新发表的主题仍然存于原始表（forum_thread）
   移动到存档表中的主题，会在主题所在的版块下建立一个存档区，通过存档区可浏览存档表中的主题。
   存档表中的主题，只供浏览，不可回复、评分，不能进行管理操作，但可以删除和移动到非存档区。

帖子分表：
   帖子没有存档的概念
   可以任意创建帖子分表（分表时创建新表或选择已存在分表）
   一次分表操作可移动100MB的整数倍数据
   根据主题表中最后回复时间正序排列的主题（first=1）tid 来获取帖子数据的
   并将该主题的所有帖子移到目标表中
   更新主题表中 posttableid 这个字段，来标识帖子的存储表

关闭论坛
关闭论坛监控
关闭数据库自动备份
主题先不分
第一个 100MB 用了 75 分钟，后来发现问题，数据库恢复了一下
然后1G用了1个半小时，估计恢复的时候顺便“优化”了

转移后打开帖子提示“没有找到帖子”，或者优化后打开帖子提示“没有找到帖子”，只要在数据库里“修复”一下就行了。（在Navicat“对象”中选中所有表，右键分析）

xoyozo 10 年前

8,068

1 2 3

一、程序上传的用户与执行 PHP 的用户不同（例如程序代码通过 SSH 上传（root 用户），而 PHP 以 www 身份运行）

二、程序上传的用户与执行 PHP 的用户相同（例如程序代码通过 FTP 上传，且和 PHP 一样，都使用 www 用户）

其它案例

大家在看

最新发布

查询 / 检测

编程

前端

行业

本站 API

博客 (26)

一、程序上传的用户与执行 PHP 的用户不同（例如程序代码通过 SSH 上传（root 用户），而 PHP 以 www 身份运行）

二、程序上传的用户与执行 PHP 的用户相同（例如程序代码通过 FTP 上传，且和 PHP 一样，都使用 www 用户）

其它案例

大家在看

最新发布