Cách khắc phục sự cố trang web thường gặp trên server Linux

Mọi người đều gặp sự cố với web server hoặc trang web của họ vào lúc này hay lúc khác. Học cách xem xét khi bạn gặp sự cố và thành phần nào có thể là thủ phạm sẽ giúp bạn khắc phục những sự cố này một cách nhanh chóng mà ít thất vọng hơn.

---

Trong hướng dẫn này, ta sẽ thảo luận cách khắc phục những vấn đề này để bạn có thể cài đặt và chạy trang web của bạn như bình thường.

Những loại vấn đề nào là điển hình?

Mặc dù đôi khi một số vấn đề có thể phát sinh không điển hình, nhưng phần lớn các vấn đề bạn sẽ gặp phải khi cố gắng cài đặt và chạy trang web của bạn rơi vào một phổ rất dễ đoán.

Ta sẽ đi sâu hơn về những vấn đề này trong các phần bên dưới, nhưng hiện tại, đây là danh sách kiểm tra đơn giản gồm các mục cần xem xét:

• Web server của bạn đã được cài đặt chưa?
• Web server có đang chạy không?
• Cú pháp của các file cấu hình web server của bạn có đúng không?
• Các cổng bạn đã cấu hình có mở (không bị firewall chặn) không?
• Cài đặt DNS của bạn có hướng bạn đến đúng nơi không?
• Tài liệu root có trỏ đến vị trí các file của bạn không?
• Web server của bạn có đang cung cấp các file index chính xác không?
• Các quyền và quyền sở hữu cấu trúc file và folder có chính xác không?
• Bạn có đang hạn chế quyền truy cập thông qua các file cấu hình của bạn không?
• Nếu bạn có một chương trình backend database , nó có đang chạy không?
• Trang web có thể kết nối thành công với database không?
• Web server của bạn có được cấu hình để chuyển nội dung động đến bộ xử lý tập lệnh không?

Đây là một số vấn đề phổ biến mà administrator gặp phải khi trang web hoạt động không chính xác. Vấn đề chính xác thường có thể được thu hẹp bằng cách xem các file log của các thành phần khác nhau và bằng cách tham chiếu các trang lỗi được hiển thị trong trình duyệt của bạn.

Dưới đây, ta sẽ xem xét từng tình huống này để bạn có thể đảm bảo dịch vụ của bạn được cấu hình chính xác.

Kiểm tra Nhật ký

Trước khi cố gắng tìm ra sự cố một cách mù quáng, hãy cố gắng kiểm tra log của web server và bất kỳ thành phần liên quan nào. Chúng thường nằm trong /var/log trong một folder con cụ thể cho dịch vụ.

Ví dụ: nếu bạn có server Apache chạy trên server Ubuntu, theo mặc định, log sẽ được lưu trong /var/log/apache2 . Kiểm tra các file trong folder này để xem loại thông báo lỗi nào đang được tạo. Nếu bạn có một chương trình backend database đang gây cho bạn sự cố, điều đó có thể sẽ giữ các bản ghi của nó trong /var/log .

Những điều khác cần kiểm tra là liệu bản thân các quy trình có để lại thông báo lỗi cho bạn khi các dịch vụ được khởi động hay không. Nếu bạn cố gắng truy cập một trang web và gặp lỗi, trang lỗi cũng có thể chứa các manh mối (mặc dù không cụ thể như các dòng trong file log ).

Sử dụng công cụ tìm kiếm để cố gắng tìm thông tin liên quan có thể chỉ cho bạn đúng hướng. Các bước dưới đây có thể giúp bạn khắc phục sự cố thêm.

Server Web của bạn đã được cài đặt chưa?

Điều đầu tiên bạn cần để phục vụ các trang web của bạn một cách chính xác là một web server .

Hầu hết mọi người sẽ cài đặt một server trước khi đến thời điểm này, nhưng có một số tình huống mà bạn có thể đã thực sự vô tình gỡ cài đặt server khi thực hiện các hoạt động gói khác.

Nếu bạn đang sử dụng hệ thống Ubuntu hoặc Debian và muốn cài đặt web server Apache, có thể chạy lệnh:

sudo apt-get update sudo apt-get install apache2 

Trên các hệ thống này, quá trình Apache được gọi là apache2 .

Nếu bạn đang chạy Ubuntu hoặc Debian và muốn web server Nginx, có thể chạy lệnh:

sudo apt-get update sudo apt-get install nginx 

Trên các hệ thống này, tiến trình Nginx được gọi là nginx .

Nếu bạn đang chạy CentOS hoặc Fedora và muốn sử dụng web server Apache, bạn có thể nhập mã này. Bạn có thể xóa “sudo” nếu bạn đã đăng nhập bằng quyền root:

sudo yum install httpd 

Trên các hệ thống này, quá trình Apache được gọi là httpd .

Nếu bạn đang chạy CentOS hoặc Fedora và muốn sử dụng Nginx, bạn có thể nhập điều này. , hãy xóa “sudo” nếu bạn đã đăng nhập bằng quyền root:

sudo rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm sudo yum install nginx 

Trên các hệ thống này, tiến trình Nginx được gọi là nginx .

Server Web của bạn có đang chạy không?

Đến đây bạn chắc chắn rằng server của bạn đã được cài đặt, nó đang chạy?

Có rất nhiều cách để tìm hiểu xem dịch vụ có đang chạy hay không. Một phương pháp khá đa nền tảng là sử dụng netstat .

Điều này sẽ cho bạn biết tất cả các quy trình đang sử dụng các cổng trên server . Sau đó ta có thể grep cho tên của quá trình ta đang tìm kiếm:

sudo netstat -plunt | grep apache2 

---

tcp6       0      0 :::80           :::*            LISTEN      2000/apache2 

Bạn nên thay đổi “apache2” thành tên của tiến trình web server trên server của bạn. Nếu bạn nhìn thấy một dòng giống như ở trên, điều đó nghĩa là quá trình của bạn đang hoạt động. Nếu bạn không nhận lại được bất kỳ kết quả nào, điều đó nghĩa là bạn đã truy vấn sai quy trình hoặc web server của bạn không chạy.

Nếu đúng như vậy, bạn có thể bắt đầu bằng cách sử dụng phương pháp ưu tiên của phân phối. Ví dụ: trên Ubuntu, bạn có thể khởi động dịch vụ Apache2 bằng lệnh :

sudo service apache2 start 

Trên CentOS, bạn có thể gõ thông tin như sau:

sudo /etc/init.d/httpd start 

Nếu web server của bạn khởi động, bạn có thể kiểm tra lại bằng netstat để xác minh mọi thứ đều chính xác.

Cú pháp của file cấu hình web server của bạn có chính xác không?

Nếu web server của bạn từ chối khởi động, thường thì đây là dấu hiệu cho thấy các file cấu hình của bạn cần được chú ý. Cả Apache và Nginx đều yêu cầu tuân theo nghiêm ngặt cú pháp lệnh của chúng để có thể đọc các file .

Các file cấu hình cho các dịch vụ này thường nằm trong một folder con của folder /etc/ được đặt tên theo chính tiến trình.

Do đó, ta có thể truy cập folder cấu hình chính của Apache trên Ubuntu bằng lệnh :

<pre>
cd / etc / <span class = “highlight”> apache2 </span>
</pre>

Theo cách tương tự, folder cấu hình Apache trên CentOS cũng phản ánh tên CentOS cho quá trình đó:

<pre>
cd / etc / <span class = “highlight”> httpd </span>
</pre>

Cấu hình sẽ được trải ra giữa nhiều file khác nhau. Nếu dịch vụ của bạn không khởi động được, nó thường sẽ trỏ bạn đến file cấu hình và dòng nơi phát hiện sự cố đầu tiên. Kiểm tra file đó để tìm lỗi.

Mỗi web server này cũng cung cấp cho bạn khả năng kiểm tra cú pháp cấu hình file của bạn.

Nếu bạn đang sử dụng Apache, bạn có thể sử dụng lệnh apache2ctl hoặc apachectl để kiểm tra các file cấu hình của bạn để tìm lỗi cú pháp:

apache2ctl configtest 

---

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message Syntax OK 

Như bạn thấy ở trên, ta đã nhận được thông báo cung cấp thông tin về một chi tiết trong cấu hình của ta , nhưng không có lỗi. Điều này là tốt.

Nếu bạn có web server Nginx, bạn có thể chạy một bài kiểm tra tương tự bằng lệnh :

sudo nginx -t 

---

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful 

Như bạn thấy , quá trình này cũng kiểm tra cú pháp của bạn. Nếu ta xóa dấu chấm phẩy kết thúc khỏi một dòng trong file (lỗi phổ biến đối với cấu hình Nginx), bạn sẽ nhận được thông báo như sau:

sudo nginx -t  

---

nginx: [emerg] invalid number of arguments in "tcp_nopush" directive in /etc/nginx/nginx.conf:18 nginx: configuration file /etc/nginx/nginx.conf test failed 

Có số lượng đối số không hợp lệ vì Nginx tìm kiếm dấu chấm phẩy để kết thúc các câu lệnh. Nếu nó không tìm thấy một, nó sẽ xuống dòng tiếp theo và giải thích đó là các đối số tiếp theo cho dòng cuối cùng.

Bạn có thể chạy các bài kiểm tra này để tìm các vấn đề về cú pháp trong file của bạn . Khắc phục các sự cố mà nó tham chiếu cho đến khi bạn có thể nhận được các file để vượt qua bài kiểm tra.

Các cổng bạn đã cấu hình có mở không?

Nói chung, các web server chạy trên cổng 80 cho truy cập web bình thường và sử dụng cổng 443 cho truy cập được mã hóa bằng TLS / SSL. Để bạn có thể truy cập trang web một cách chính xác, các cổng này phải được làm cho có thể truy cập được.

Bạn có thể kiểm tra xem server của bạn có mở cổng hay không bằng cách sử dụng netcat từ máy local của bạn.

Bạn chỉ cần sử dụng địa chỉ IP của server và cho nó biết cổng nào bạn muốn kiểm tra, như sau:

sudo nc -z 111.111.111.111 80 

Thao tác này sẽ kiểm tra xem cổng 80 có đang mở trên server tại 111.111.111.111 . Nếu nó đang mở, lệnh sẽ trở lại ngay lập tức. Nếu nó không được mở, lệnh sẽ liên tục cố gắng tạo kết nối, không thành công. Bạn có thể dừng quá trình này bằng cách nhấn CTRL-C trong cửa sổ dòng lệnh.

Nếu các cổng web của bạn không thể truy cập được, bạn nên xem cấu hình firewall của bạn . Bạn có thể cần mở cổng 80 hoặc cổng 443.

Cài đặt DNS của bạn có đang hướng bạn đến đúng nơi không?

Nếu bạn có thể truy cập trang web của bạn thông qua địa chỉ IP, nhưng không phải thông qua domain , bạn có thể cần phải xem cài đặt DNS của bạn .

Để khách truy cập có thể truy cập trang web thông qua domain của nó, bạn phải có bản ghi “A” hoặc “AAAA” trỏ đến địa chỉ IP server của bạn trong cài đặt DNS. Bạn có thể truy vấn bản ghi “A” cho domain của bạn bằng cách chạy lệnh sau:

<pre>
host -t A <span class = “highlight”> example.com </span>
</pre>
<pre>
<span class = “highlight”> example.com </span> có địa chỉ 93.184.216.119
</pre>

Dòng được trả về cho bạn phải trùng với địa chỉ IP của server của bạn. Nếu bạn cần kiểm tra bản ghi “AAAA” (đối với kết nối IPv6), có thể chạy lệnh:

<pre>
host -t AAAA <span class = “highlight”> example.com </span>
</pre>
<pre>
<span class = “highlight”> example.com </span> có địa chỉ IPv6 2606: 2800: 220: 6d: 26bf: 1447: 1097: aa7
</pre>

Lưu ý bất kỳ thay đổi nào bạn thực hiện đối với bản ghi DNS sẽ mất khá nhiều thời gian để phổ biến. Bạn có thể nhận được kết quả không nhất quán cho các truy vấn này sau khi thay đổi vì yêu cầu của bạn thường sẽ gặp các server khác nhau chưa được cập nhật tất cả.

Nếu bạn đang sử dụng DigitalOcean, bạn có thể tìm hiểu cách cấu hình cài đặt DNS cho domain của bạn tại đây.

Đảm bảo rằng các file cấu hình của bạn cũng xử lý domain của bạn một cách chính xác

Nếu cài đặt DNS của bạn chính xác, bạn cũng có thể cần kiểm tra file server ảo Apache hoặc file khối server Nginx đảm bảo rằng chúng được cấu hình để phản hồi các yêu cầu cho domain của bạn.

Trong Apache, phần của file server ảo của bạn có thể trông giống như sau:

<pre>
<VirtualHost *: 80>
<span class = “highlight”> ServerName example.com </span>
<span class = “highlight”> ServerAlias www.example.com </span>
ServerAdmin admin@example.com
DocumentRoot / var / www / html
…
</pre>

Server ảo này được cấu hình để đáp ứng mọi yêu cầu trên cổng 80 cho domain example.com .

Một đoạn tương tự trong Nginx có thể trông giống như sau:

<pre>
người phục vụ {
nghe 80 server mặc định ;
nghe [::]: 80 server mặc định ipv6only = on;
root / usr / share / nginx / html;
index index.html index.htm;
<span class = “highlight”> server_name example.com www.example.com ; </span>
…
</pre>

Khối này được cấu hình để đáp ứng cùng một loại yêu cầu mà ta đã thảo luận ở trên.

Gốc tài liệu có trỏ đến vị trí file của bạn không?

Một cân nhắc khác là liệu web server của bạn có được trỏ đến đúng vị trí file hay không.

Mỗi server ảo trong Apache hoặc khối server trong Nginx được cấu hình để trỏ đến một folder cụ thể. Nếu cấu hình này không đúng, server sẽ thông báo lỗi khi bạn cố gắng truy cập trang.

Trong Apache, root tài liệu được cấu hình thông qua chỉ thị DocumentRoot :

<pre>
<VirtualHost *: 80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin admin@example.com
<span class = “highlight”> DocumentRoot / var / www / html </span>
…
</pre>

Dòng này cho Apache biết rằng nó nên tìm kiếm các file cho domain này trong folder /var/www/html .Nếu file của bạn được lưu ở nơi khác, bạn sẽ phải sửa đổi dòng này để trỏ đến đúng vị trí.

Trong Nginx, chỉ thị root cấu hình tương tự:

<pre>
người phục vụ {
nghe 80 server mặc định ;
nghe [::]: 80 server mặc định ipv6only = on;
<span class = “highlight”> root / usr / share / nginx / html; </span>
index index.html index.htm;
server_name example.com www.example.com ;
…
</pre>

Trong cấu hình này, Nginx tìm kiếm các file cho domain này trong folder /usr/share/nginx/html .

Server Web của bạn có đang cung cấp các file index chính xác không?

Nếu root tài liệu của bạn là chính xác và các trang index của bạn không được cung cấp chính xác khi bạn truy cập trang web hoặc vị trí folder trên trang web của bạn , bạn có thể đã cấu hình index của bạn không chính xác.

Khi khách truy cập yêu cầu một folder , thông thường server của bạn cần cung cấp cho họ một file index . Đây thường là index.html hoặc index.php tùy thuộc vào cấu hình của bạn.

Trong Apache, bạn có thể tìm thấy một dòng trong file server ảo của bạn cấu hình thứ tự index sẽ được sử dụng cho các folder cụ thể một cách rõ ràng, như sau:

<pre>
<Thư mục / var / www / html>
<span class = “highlight”> DirectoryIndex index.html index.php </span>
</Directory>
</pre>

Điều này nghĩa là khi folder đang được phục vụ, Apache sẽ tìm kiếm một file có tên là index.html trước tiên và cố gắng phục vụ index.php như một bản backup nếu file đầu tiên không được tìm thấy.

Bạn có thể đặt thứ tự sẽ được sử dụng để cung cấp file index cho toàn bộ server bằng cách chỉnh sửa file mods-enabled/dir.conf , file này sẽ đặt giá trị mặc định cho server . Nếu server của bạn không cung cấp file index , hãy đảm bảo bạn có file index trong folder trùng với một trong các tùy chọn trong file của bạn.

Trong Nginx, chỉ thị thực hiện điều này được gọi là index và nó được sử dụng như sau:

<pre>
người phục vụ {
nghe 80 server mặc định ;
nghe [::]: 80 server mặc định ipv6only = on;
root / usr / share / nginx / html;
<span class = “highlight”> index index.html index.htm; </span>
server_name example.com www.example.com ;
…
</pre>

Quyền và Quyền sở hữu có được đặt chính xác không?

Để web server phân phối file một cách chính xác, nó phải có khả năng đọc file và có quyền truy cập vào folder nơi chúng được lưu giữ. Điều này có thể được kiểm soát thông qua quyền và quyền sở hữu đối với file và folder .

Để đọc file , các folder chứa nội dung phải có thể đọc được và thực thi được bởi quy trình web server . Tên user và group được sử dụng để chạy web server khác với bản phân phối.

Trên Ubuntu và Debian, cả Apache và Nginx đều chạy với quyền user www-data là thành viên của group www-data .

Trên CentOS và Fedora, Apache chạy dưới một user gọi là apache thuộc group apache . Nginx chạy dưới user có tên là nginx , là một phần của group nginx .

Sử dụng thông tin này, Bạn có thể xem các folder và file tạo nên nội dung trang web của bạn :

<pre>
ls -l <span class = “highlight”> / path / to / web / root </span>
</pre>

Các folder phải có thể đọc và thực thi được bởi user web hoặc group , và các file phải có thể đọc được để đọc nội dung.Để tải lên, viết hoặc sửa đổi nội dung, các folder cũng phải có thể ghi được và các file cũng cần phải được ghi. Tuy nhiên, hãy hết sức thận trọng đặt các folder có thể ghi được vì nó có thể là một rủi ro bảo mật.

Để sửa đổi quyền sở hữu file , bạn có thể làm như sau:

<pre>
sudo chown <span class = “highlight”> chủ sở hữu user </span>: <span class = “highlight”> chủ sở hữu group </span> <span class = “highlight”> / path / to / file </span>
</pre>

Điều này cũng có thể được thực hiện đối với một folder . Bạn có thể thay đổi quyền sở hữu của một folder và tất cả các file trong nó bằng cách chuyển cờ -R :

<pre>
sudo chown -R <span class = “highlight”> chủ sở hữu user </span>: <span class = “highlight”> chủ sở hữu group </span> <span class = “highlight”> / path / to / file </ span >
</pre>

Bạn có thể tìm hiểu thêm về các quyền của Linux tại đây.

Bạn có đang hạn chế quyền truy cập thông qua các file cấu hình của bạn không?

Có thể cấu hình của bạn được cài đặt để từ chối quyền truy cập từ các file bạn đang cố gắng cung cấp.

Trong Apache, điều này sẽ được cấu hình trong file server ảo cho trang web đó hoặc thông qua .htaccess nằm trong chính folder .

Trong các file này, có thể hạn chế quyền truy cập theo một số cách khác nhau. Các folder có thể bị hạn chế như thế này trong Apache 2.4:

<pre>
<Thư mục / usr / share>
AllowOverride Không có
<span class = “highlight”> Yêu cầu tất cả bị từ chối </span>
</Directory>
</pre>

Dòng này nói với web server không cho phép bất kỳ ai truy cập vào nội dung của folder này. Trong Apache 2.2 trở xuống, điều này sẽ được viết như thế này:

<pre>
<Thư mục / usr / share>
AllowOverride Không có
<span class = “highlight”> Từ chối đơn hàng, cho phép </span>
<span class = “highlight”> Từ chối tất cả </span>
</Directory>
</pre>

Nếu bạn tìm thấy một chỉ thị như thế này cho folder chứa nội dung bạn đang cố truy cập, điều này sẽ ngăn cản thành công của bạn.

Trong Nginx, những hạn chế này sẽ ở dạng deny chỉ thị và sẽ nằm trong khối server hoặc file cấu hình chính của bạn:

<pre>
location / usr / share {
<span class = “highlight”> từ chối tất cả; </span>
}
</pre>

Nếu bạn có Chương trình backend database , nó có đang chạy không?

Nếu trang web dựa trên backend database như MySQL, PostreSQL, MongoDB, v.v. thì bạn cần đảm bảo nó đã được cài đặt và chạy.

Bạn có thể làm điều đó giống như cách bạn đã kiểm tra xem web server có đang chạy hay không. , ta có thể tìm kiếm các quy trình đang chạy và sau đó chọn tên của quy trình ta đang tìm kiếm:

<pre>
sudo netstat -plunt | grep <span class = “highlight”> mysql </span>
</pre>
<pre>
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 3356 / <span class = “highlight”> mysql </span> d
</pre>

Như bạn thấy , dịch vụ đang chạy trên máy này. Đảm bảo rằng bạn biết tên mà dịch vụ của bạn sử dụng khi tìm kiếm nó.

Một giải pháp thay thế là tìm kiếm cổng mà dịch vụ của bạn chạy nếu bạn biết điều đó. Xem tài liệu cho database của bạn để tìm cổng mặc định mà nó chạy trên đó hoặc kiểm tra các file cấu hình của bạn.

Nếu bạn có Backend Database , Trang web có thể Kết nối Thành công không?

Bước tiếp theo cần thực hiện nếu bạn đang khắc phục sự cố với backend database là xem liệu bạn có thể kết nối chính xác hay không.Điều này thường nghĩa là kiểm tra các file mà trang web đọc để tìm ra thông tin database .

Ví dụ, đối với một trang WordPress, cài đặt kết nối database được lưu trữ trong một file có tên wp-config.php . Bạn cần phải xem xét rằng việc DB_NAME , DB_USER , và DB_PASSWORD là chính xác để cho trang web để kết nối với database .

Bạn có thể kiểm tra xem file có thông tin chính xác hay không bằng cách cố gắng kết nối với database theo cách thủ công bằng một số thứ như:

<pre>
mysql -u <span class = “highlight”> DB USER value </span> -p <span class = “highlight”> DB PASSWORD value </span> <span class = “highlight”> DB NAME value </span>
</pre>

Nếu bạn không thể kết nối bằng các giá trị bạn tìm thấy trong file , bạn có thể cần tạo account và database chính xác hoặc sửa đổi quyền truy cập database của bạn .

Web server của bạn có được cấu hình để chuyển nội dung động đến bộ xử lý tập lệnh không?

Nếu bạn đang sử dụng chương trình backend database , bạn gần như chắc chắn đang sử dụng một ngôn ngữ lập trình như PHP để xử lý yêu cầu nội dung động, tìm nạp thông tin từ database và hiển thị kết quả.

Nếu đúng như vậy, bạn cần đảm bảo web server của bạn được cấu hình chính xác để chuyển các yêu cầu đến bộ xử lý tập lệnh.

Trong Apache, điều này thường nghĩa là đảm bảo mod_php5 được cài đặt và kích hoạt. Bạn có thể làm điều đó trên Ubuntu hoặc Debian bằng lệnh :

sudo apt-get update sudo apt-get install php5 libapache2-mod-php5 sudo a2enmod php5 

Đối với hệ thống CentOS / Fedora, bạn sẽ phải nhập:

sudo yum install php php-mysql sudo service httpd restart 

Trong Nginx, điều này phức tạp hơn một chút. Nginx không có module PHP có thể được kích hoạt, vì vậy ta cần đảm bảo ta đã cài đặt và bật php-fpm trong cấu hình của bạn .

Trên server Ubuntu hoặc Debian, đảm bảo các thành phần được cài đặt bằng lệnh :

sudo apt-get update sudo apt-get install php5-fpm php5-mysql 

Trên CentOS hoặc Fedora, bạn thực hiện việc này bằng lệnh :

sudo yum install php-fpm php-mysql 

Vì PHP processor không phải là một phần của Nginx, bạn cần yêu cầu nó chuyển các file PHP một cách rõ ràng. Làm theo bước bốn của hướng dẫn này để tìm hiểu cách cấu hình Nginx để chuyển file PHP sang php-fpm . Bạn cũng nên xem phần của bước ba liên quan đến cấu hình PHP processor . Điều này sẽ khá giống nhau dù phân phối của bạn.

Nếu vẫn thất bại, hãy kiểm tra lại log

Kiểm tra log thực sự nên là bước đầu tiên của bạn, nhưng nó cũng là bước cuối cùng tốt trước khi yêu cầu thêm trợ giúp.

Nếu bạn đã hết khả năng tự khắc phục sự cố và cần trợ giúp (từ bạn bè, bằng cách mở phiếu hỗ trợ, v.v.), bạn sẽ nhận được trợ giúp phù hợp nhanh hơn bằng cách cung cấp file log và thông báo lỗi. Các administrator có kinh nghiệm có thể sẽ có ý tưởng tốt về những gì đang xảy ra nếu bạn cung cấp cho họ những phần thông tin mà họ cần.

Kết luận

Hy vọng rằng các mẹo khắc phục sự cố này sẽ giúp bạn tìm ra và khắc phục một số vấn đề phổ biến hơn mà administrator gặp phải khi cố gắng cài đặt và chạy trang web của họ.

Nếu bạn có mẹo bổ sung nào về những thứ cần kiểm tra và cách giải quyết vấn đề, vui lòng chia sẻ chúng với những user khác trong phần comment .

<div class = “author”> Bởi Justin Ellingwood </div>

---

---

Các tin liên quan

Cách Fail2Ban hoạt động để bảo vệ các dịch vụ trên server Linux
2014-05-07
Cách cài đặt Linux, Nginx, MySQL, PHP (LEMP) trên Ubuntu 14.04
2014-04-25
Cách cài đặt Linux, Apache, MySQL, PHP (LAMP) trên Ubuntu 14.04
2014-04-18
Thiết lập server ban đầu với Ubuntu 14.04
2014-04-17
Giới thiệu về công cụ nén tệp trên server Linux
2014-04-15
Cách tải phần mềm và nội dung lên VPS Linux của bạn
2014-04-14
Cách bảo vệ server của bạn chống lại lỗ hổng bảo mật OpenSSL.
2014-04-08
Cách cấu hình mail server bằng Postfix, Dovecot, MySQL và SpamAssassin
2014-04-01
Cách cấu hình mail server bằng Postfix, Dovecot, MySQL và SpamAssassin
2014-04-01
Cách cấu hình công cụ để sử dụng IPv6 trên VPS Linux
2014-04-01