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、伺服器硬體故障，如風扇不轉、內存不識別、硬碟損壞等。