php发包

A. php万网空间被关停，网站是否受到攻击

和我网站之前的情况一样！

最主要原因是你网站程序有漏洞，才导致的被黑客入侵，利用的是php 向外发包，导致万网检测到你进程以及流量都有异常才会被万网关掉！

我之前用dedecms做的公司网站，当时也是被万网给关掉了网站，说我网站进程有异常，一开始不懂安全，找程序员朋友看了看代码，说是我这段代码的意思是网站流量向外发包攻击别人。我跟万网也交流过，但我毕竟是新手不懂的原因，找了几个做网站的朋友咨询了一下，确定了是自己网站的程序安全有问题~！朋友他们也推荐了给我一家专业做网站安全的sinesafe公司。问题才得以解决，希望我上面的回答能帮到楼主，经历了才知道，互联网的路上还有很多的路要走，帮助别人也是在帮助我自己。
问题真的解决了，我也不需要你怎么感谢我，只希望你给我一个承诺！以后遇到有困难的人，一定要尽力的去帮助有困难的人！

我找了一些关于安全方面的建议 你可以看看！

建站一段时间后总能听得到什么什么网站被挂马，什么网站被黑，被攻击。好像入侵挂马似乎是件很简单的事情。其实，入侵不简单，简单的是你的网站的必要安全措施并未做好。

一：挂马预防措施：

1、建议用户通过ftp来上传、维护网页，尽量不安装asp的上传程序。

2、定期对网站进行安全的检测，具体可以利用网上一些工具，如sinesafe网站挂马检测工具！

序，只要可以上传文件的asp都要进行身份认证!

3、asp程序管理员的用户名和密码要有一定复杂性，不能过于简单，还要注意定期更换。

4、到正规网站下载asp程序，下载后要对其数据库名称和存放路径进行修改，数据库文件名称也要有一定复杂性。

5、要尽量保持程序是最新版本。

6、不要在网页上加注后台管理程序登陆页面的链接。

7、为防止程序有未知漏洞，可以在维护后删除后台管理程序的登陆页面，下次维护时再通过ftp上传即可。

8、要时常备份数据库等重要文件。

9、日常要多维护，并注意空间中是否有来历不明的asp文件。记住：一分汗水，换一分安全!

10、一旦发现被入侵，除非自己能识别出所有木马文件，否则要删除所有文件。

11、对asp上传程序的调用一定要进行身份认证，并只允许信任的人使用上传程序。这其中包括各种新闻发布、商城及论坛程

二：挂马恢复措施：

1.修改帐号密码

不管是商业或不是，初始密码多半都是admin。因此你接到网站程序第一件事情就是“修改帐号密码”。帐号

密码就不要在使用以前你习惯的，换点特别的。尽量将字母数字及符号一起。此外密码最好超过15位。尚若你使用

SQL的话应该使用特别点的帐号密码，不要在使用什么什么admin之类，否则很容易被入侵。

2.创建一个robots.txt

Robots能够有效的防范利用搜索引擎窃取信息的骇客。

3.修改后台文件

第一步：修改后台里的验证文件的名称。

第二步：修改conn.asp，防止非法下载，也可对数据库加密后在修改conn.asp。

第三步：修改ACESS数据库名称，越复杂越好，可以的话将数据所在目录的换一下。

4.限制登陆后台IP

此方法是最有效的，每位虚拟主机用户应该都有个功能。你的IP不固定的话就麻烦点每次改一下咯，安全第一嘛。

5.自定义404页面及自定义传送ASP错误信息

404能够让骇客批量查找你的后台一些重要文件及检查网页是否存在注入漏洞。

ASP错误嘛，可能会向不明来意者传送对方想要的信息。

6.慎重选择网站程序

注意一下网站程序是否本身存在漏洞，好坏你我心里该有把秤。

7.谨慎上传漏洞

据悉，上传漏洞往往是最简单也是最严重的，能够让黑客或骇客们轻松控制你的网站。

可以禁止上传或着限制上传的文件类型。不懂的话可以找专业做网站安全的sinesafe公司。

8. cookie 保护

登陆时尽量不要去访问其他站点，以防止 cookie 泄密。切记退出时要点退出在关闭所有浏览器。

9.目录权限

请管理员设置好一些重要的目录权限，防止非正常的访问。如不要给上传目录执行脚本权限及不要给非上传目录给于写入权。

10.自我测试

如今在网上黑客工具一箩筐，不防找一些来测试下你的网站是否OK。

11.例行维护

a.定期备份数据。最好每日备份一次，下载了备份文件后应该及时删除主机上的备份文件。

b.定期更改数据库的名字及管理员帐密。

c.借WEB或FTP管理，查看所有目录体积，最后修改时间以及文件数，检查是文件是否有异常，以及查看是否有异常的账号。

B. nginx中request_time和upstream_response_time详解

背景

最近监控报警有短暂的502，赶紧分析问题原因，查看nginx的access_log 发现短暂报警的request_time比较大，但是upstream_response_time有2个值，一个比较小，一个比较大，日志如下：

request:GET /index/all HTTP/1.1 request_time:30.049 up_resp_time:0.015 : 30.033up_addr:11.11.11.11:80 : 22.22.22.22:80 bytes:556 status:502概念

request_time

官网描述：

request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client 。

指的就是从接受用户请求的第一个字节到发送完响应数据的时间，即包括接收请求数据时间、程序响应时间、输出响应数据时间。

upstream_response_time

官网描述：

keeps times of responses obtained from upstream servers; times are kept in seconds with a milliseconds resolution. Several response times are separated by commas and colons like addresses in the $upstream_addr variable

是指从Nginx向后端php-fpm建立连接开始到接受完数据然后关闭连接为止的时间。

分析

从上面的描述可以看出，$request_time肯定比$upstream_response_time值大，特别是使用POST方式传递参数时，因为Nginx会把request body缓存住，接收完毕后才会把数据一起发给后端。所以如果用户网络较差，或者传递数据较大时，$request_time会比$upstream_response_time大很多。

所以如果使用nginx的accesslog查看php程序中哪些接口比较慢的话，记得在log_format中加入$upstream_response_time。

我们的情况是request_time比较大，猜测有可能是如下问题产生的：

用户端网络问题

tcp传输如果分包时，每个tcp包大约1400字节，之前那个请求响应body有1500K左右，要分成100多个tcp包。tcp有个慢启动过程，起初每次发送10个包，之后再根据网络情况调整每次发包数量，假设网络不好，就得分10次发送。然后由于tcp是可靠传输，需要确保每个包对方都收到了（通过给每个包编序号，以及接收对方发送的ack实现），如果在约定时间内没收到对方发的ack会重传该包。此外，tcp有发送窗口的概念，假设发送窗口为10，那么一次性可以发送10个包，之后每收到一个ack才能把这个包对应的发送窗口位置空余出来，发送下一个包。因此，用户端网络不好是会影响响应body全部发完的时间，进而影响nginx日志中request_time的时间。

请求响应body体过大 因为请求接口输出的数据中有些过大的无用数据导致请求响应body过大导致分包发送影响了request_time

php-fpm进程处理时间过长

因此：较高的request_time可能是由于连接速度较慢的客户端造成的,高request_time不一定代表服务器和/或应用程序的性能.

在分析时,你真的不应该在request_time上花费太多时间,而是测量应用程序的响应时间(即upstream_response_time).

我们的架构比较特殊，有2套项目，一套重构的项目，一套老项目，请求会先转发到重构的新项目上，如果返回404，则再转发到老的项目上，所以我们的upstream_response_time有2个值:

up_resp_time:0.015 : 30.033up_addr:11.11.11.11:80 : 22.22.22.22:80

11.11.11.11:80 是新项目，因为返回了404，所以响应时间是 0.015很快

22.22.22.22:80 是老项目，因为处理时间过长，所以响应时间很长，超过30s

查看老项目nginx_error.log

[error] 22705#0: *692770681 recv() failed (104: Connection reset by peer) while reading response header from upstream

上面错误的两大主要原因：

1.php-fpm超时进程终止

2.可用内存不够进程终止

查看php-fpm配置

request_terminate_timeout = 30

我们得出结论：nginx告诉我们没有收到反馈，php-fpm告诉我们进程中断了

再查看老乡们的access.log

up_resp_time": "30.029","request_time": "30.030

up_resp_time超过30s，结合我们php-fpm.conf的配置和上面的报错,可以肯定就是执行时间太长了

再去查看php-slow.log 发现是因为请求一个外部接口导致的过慢

解决方案

调用外部接口增加超时时间，避免过长时间占用php-fpm

总结

对偶然出现的少量响应时间长的问题，可能是外部影响、网络异常等造成

偶然出现少量响应时间过长时，可以排查以下几个方面来定位问题，

查看当时服务器日志是否有错误；

检查服务器资源使用情况是否正常，load average、CPU使用率（尤其是单核CPU）是否有飙高现象；

检查是否出现磁盘短暂负载较高，比如iostat util%飙高等；

确认当时网络情况是否正常，是否有网络丢包等现象。 以上排查建议在有全面监控的基础上进行，偶现问题比较难定位，有全面的监控数据进行排查就方便多了。

参考：https://www.phpmianshi.com/?id=123

原文：https://juejin.cn/post/7098596541794877448

C. 我的vps一直能用，从昨天早上就不能用了，通过ping 我的ip还是通的 但是打开网站就是空白页但是在重启一下

第1层：网站本身的原因：
1、网站程序设计错误。
2、因程序漏洞或没有及时升级，被黑客植入木马。
3、域名解析不正常。
4、国内服务器上，域名没有备案。
5、出现违反法律或政策的内容，被服务商关闭。
第2层：服务器内部的原因：
1、服务器配置和网站程序要求不符。比如网站是PHP+MySQL的，但服务器上没有安装MySQL。
2、整个服务器被黑客入侵，在全部网站上植入了木马。
3、服务器的CPU、负载、内存使用过高。具体原因可能是某个客户的程序设计不合理，或者对外发包。
4、服务器受到来自外部的DDOS或CC攻击。
5、服务器出现严重违法问题，机房拔线或封IP。
6、服务器硬件故障，如风扇不转、内存不识别、硬盘损坏等。