Domain chưa trỏ đúng: Quy trình bắt bệnh 5 tầng từ Registrar, DNS đến NGINX Web Server

Phạm vi thực hành: Tên miền thử nghiệm lab-cf02.localhost.vn và máy chủ VPS Ubuntu 24.04 LTS thuộc quyền quản lý trực tiếp. Bài viết sử dụng số liệu đo đạc thực tế tại tầng DNS/Origin ngày 30/09 và đợt thực nghiệm định tuyến NGINX trên cổng loopback ngày 01/10/2026. Các nhánh chẩn đoán về việc đổi Registrar, lỗi DNSSEC hay cấu hình Cloudflare Proxy được biên soạn thành quy trình chuẩn để bạn tra cứu khi gặp sự cố tương ứng.

Trong nghề vận hành web, câu cảm thán “Ủa sao domain chưa trỏ đúng vậy anh?” có lẽ là câu nói mơ hồ nhất quả đất. Đằng sau bốn chữ “không vào được” đó có thể là cả chục kịch bản hoàn toàn khác nhau: tên miền chưa phân giải ra IP, đang trả về IP của server cũ, hiện nhầm giao diện của website hàng xóm trên cùng VPS, bị dính vòng lặp chuyển hướng 301 vô tận, hay đơn giản là tường lửa đang đóng cửa. Nếu bạn không có quy trình khoanh vùng mà cứ thấy lỗi là lao vào sửa bừa cả bảng điều khiển DNS lẫn file cấu hình NGINX cùng một lúc, bạn sẽ tự biến một lỗi nhỏ thành một mớ bòng bong không biết đường nào mà lần. Hãy hít sâu một hơi, ghi lại chính xác URL đầy đủ, thời điểm gặp lỗi và thông báo trên màn hình trước khi đụng tay vào bàn phím.

Khoanh vùng thủ phạm cực nhanh chỉ bằng ba câu hỏi cốt lõi

Bất kỳ sự cố tên miền nào cũng có thể được chẻ nhỏ qua ba câu hỏi tuần tự: (1) Tên miền đã phân giải ra đúng địa chỉ IP mong muốn chưa? (2) Gói tin mạng từ máy khách có chạm tới được cổng lắng nghe của Web Server không? Và (3) Khi nhận được gói tin rồi, Web Server có mở đúng thư mục chứa website đó không? Chúng ta sẽ dùng dig hoặc nslookup để trả lời câu hỏi số 1, dùng curl cho câu hỏi số 2, và soi file cấu hình Server Block cùng nhật ký access.log / error.log cho câu hỏi số 3. Nguyên tắc vàng của người làm kỹ thuật là: phát hiện bằng chứng đứt gãy ở tầng nào thì dừng lại sửa dứt điểm tầng đó, tuyệt đối không nhảy cóc.

Trước khi bắt đầu cuộc điều tra, bạn hãy để sẵn trước mặt địa chỉ IP đích của VPS (origin IP), tên Zone DNS đang quản lý, quyền truy cập bảng điều khiển và bản sao lưu cấu hình trước lần chỉnh sửa gần nhất. Lưu ý chỉ chạy các lệnh kiểm tra trên tên miền thuộc quyền quản lý của bạn. Trong môi trường thực hành này, chúng ta chỉ làm việc với nhánh lab-cf02.localhost.vn; nếu một subdomain thử nghiệm gặp trục trặc, đừng bao giờ lấy đó làm cớ để đi xóa hay sửa bản ghi của tên miền chính đang chạy ổn định.

Sơ đồ 5 tầng điều tra sự cố tên miền theo chiều từ ngoài Internet đi sâu vào trong máy chủ do đội ngũ localhost.vn biên soạn.

Tầng 1: Nhà đăng ký tên miền (Registrar) và quyền ủy quyền Nameserver (Delegation)

dig NS localhost.vn +short

Đã bao giờ bạn ngồi hì hục thêm sửa bản ghi A trên bảng điều khiển Cloudflare suốt cả buổi chiều mà gõ dig vẫn trơ trơ không đổi, đến tối mới phát hiện ra… tên miền ở nhà đăng ký (Registrar) vẫn đang trỏ Nameserver về nhà cung cấp cũ chưa? Đó là lý do tầng đầu tiên bạn phải kiểm tra luôn là cặp Nameserver (NS) đang nắm quyền điều hành thực tế. Hãy đối chiếu kết quả lệnh dig NS ở trên với đúng trang quản trị DNS mà bạn vừa thao tác; nếu hai bên lệch nhau, nghĩa là nãy giờ bạn đang sửa bản ghi ở một “vũ trụ song song” chưa hề có hiệu lực trên Internet!

Trong trường hợp bạn vừa mới đổi cặp Nameserver tại Registrar và bỗng thấy tên miền trả về lỗi SERVFAIL trên diện rộng, hãy kiểm tra ngay cấu hình bảo mật DNSSEC. Nếu ở nhà cung cấp cũ bạn có bật DNSSEC mà khi chuyển sang Nameserver mới bạn quên tắt hoặc chưa cập nhật bản ghi DS tương ứng tại Registrar, các Resolver trên thế giới sẽ coi phản hồi từ Nameserver mới là không hợp lệ và từ chối phân giải. Ngoài ra, đừng quên liếc qua trạng thái vòng đời tên miền (clientHold, serverHold hoặc hết hạn gia hạn) nếu bỗng dưng toàn bộ tên miền biến mất khỏi bản đồ mạng.

Một mẹo nhỏ nữa cho các hệ thống lớn: đôi khi một nhánh subdomain (như sub.ten-mien.com) lại được ủy quyền riêng bằng các bản ghi NS sang một hệ thống quản trị DNS độc lập hoàn toàn với tên miền cha. Vì vậy, hãy luôn đọc kỹ cấu hình thực tế thay vì mặc định rằng mọi tên miền con đều nằm chung trong một bảng điều khiển.

Tầng 2: Bản ghi DNS cụ thể (A, AAAA, CNAME) và độ trễ bộ nhớ đệm (Cache)

dig lab-cf02.localhost.vn A +noall +answer
dig lab-cf02.localhost.vn AAAA +noall +answer
dig @1.1.1.1 lab-cf02.localhost.vn A +noall +answer

Một cái bẫy cực kỳ tinh vi mà rất nhiều anh em quản trị viên từng sập hầm: bạn đổi bản ghi A (IPv4) sang địa chỉ VPS mới chuẩn chỉnh rồi, nhưng lại quên xóa hoặc quên cập nhật bản ghi AAAA (IPv6) vốn vẫn đang trỏ về chiếc máy chủ cũ! Khi đó, những người dùng sử dụng mạng di động 4G/5G hoặc cáp quang ưu tiên IPv6 sẽ âm thầm bị dẫn thẳng về máy chủ cũ, trong khi bạn ngồi trên mạng văn phòng thuần IPv4 thì lại thấy web lên hoàn hảo. Tương tự, với bản ghi bí danh CNAME, bạn phải kiểm tra đến tận đích cuối cùng xem nó phân giải ra địa chỉ IP nào, và cẩn thận lỗi gõ nhầm tên bản ghi thành lab.localhost.vn.localhost.vn do khác biệt quy ước tự động nối đuôi tên miền giữa các bảng điều khiển.

Khi thấy kết quả giữa các nơi trả về chưa đồng nhất, hãy ghi lại con số TTL hiện tại và dùng lệnh dig @TEN-NS hỏi thẳng máy chủ Authoritative Nameserver gốc. Phép đối chiếu này giúp bạn biết ngay lập tức: lỗi do bảng Zone gốc chưa lưu cấu hình, hay gốc đã đúng hoàn toàn và bạn chỉ việc ngồi rung đùi chờ vài phút cho bộ nhớ đệm của các Public Resolver hết hạn. Tuyệt đối tránh kiểu tâm lý hoảng loạn đổi IP qua lại liên tục trong lúc chờ cache.

Nếu tên miền con vừa mới được tạo ra lần đầu nhưng trước đó bạn đã lỡ gõ thử lên trình duyệt, rất có thể phản hồi NXDOMAIN đã bị lưu tạm vào bộ nhớ đệm âm (Negative Cache). Trong lúc chờ hết chu kỳ cache đó, bạn hoàn toàn không cần ngồi chơi xơi nước mà có thể dùng ngay cờ --resolve của curl ở Tầng 3 bên dưới để kiểm tra máy chủ gốc một cách độc lập.

Dữ liệu đối chiếu thực tế từ mốc ngày 30/09/2026: Vào lúc 22:48 (giờ Việt Nam), bản ghi A của tên miền lab trả về chính xác địa chỉ 103.82.26.183 với mức TTL 300 giây đồng loạt qua cả Local Resolver, Cloudflare 1.1.1.1, Google 8.8.8.8 lẫn hai máy chủ gốc arnold.ns.cloudflare.com và penny.ns.cloudflare.com. Trong khi đó, truy vấn bản ghi AAAA và CNAME trả về trạng thái NOERROR kèm 0 answer (tức tên miền hợp lệ nhưng không khai báo hai loại bản ghi này, hoàn toàn khác với lỗi đứt mạng Timeout). Vì thế, nếu bạn chạy lệnh kèm cờ +noall +answer mà thấy màn hình trống trơn, hãy bỏ cờ rút gọn đi để đọc rõ dòng status trong phần HEADER trước khi kết luận.

Ảnh chụp giao diện quản trị thực tế ngày 30/09/2026 (có gắn logo localhost.vn) ghi nhận cấu hình bản ghi A ở chế độ DNS only và mức TTL Auto. Mở ảnh ở độ phân giải gốc.

Ảnh chụp màn hình truy vấn DNS thực tế ngày 01/10/2026

Vào lúc 09:25:59 (UTC+7) ngày 01/10/2026, lệnh dig chạy trên Ubuntu của máy chủ LAB-CF-02 truy vấn bản ghi A qua 127.0.0.53 đã nhận về trạng thái NOERROR, 1 answer, mức TTL 300 và địa chỉ IP 103.82.26.183. Cặp Nameserver quản lý Zone là penny và arnold của Cloudflare; đồng thời lệnh nslookup hỏi qua 1.1.1.1 cũng trả về đúng địa chỉ IP trên kèm dòng thông báo Non-authoritative answer:

Ảnh chụp màn hình console thực tế lúc 09:25:59 ngày 01/10/2026 (UTC+7), giữ nguyên vẹn pixel vùng kết quả và thêm dải logo ở chân ảnh. Bấm vào ảnh để xem kích thước đầy đủ.

Tiếp đó, vào lúc 09:32:16 (UTC+7), truy vấn bản ghi A hỏi thẳng máy chủ gốc penny.ns.cloudflare.com (162.159.38.124) trả về cờ xác thực aa, 1 answer, mức TTL 300 và cùng địa chỉ IP 103.82.26.183. Hai truy vấn AAAA và CNAME qua 127.0.0.53 đều trả về NOERROR với ANSWER: 0:

Ảnh chụp console thực tế lúc 09:32:16 ngày 01/10/2026 (UTC+7), bảo toàn nguyên vẹn pixel vùng kết quả và gắn thêm dải logo nhận diện. Bấm vào ảnh để mở bản đầy đủ.

Tầng 3: Bóc tách tầng trung gian Cloudflare Proxy khỏi máy chủ gốc (Origin)

Rất nhiều bạn mới dùng Cloudflare một phen hú vía khi gõ dig kiểm tra tên miền của mình lại thấy trả về những dải IP lạ hoắc kiểu 104.21.x.x hay 172.67.x.x rồi tưởng tên miền bị hack! Thực ra, khi bạn bật biểu tượng đám mây cam (Proxied) trên Cloudflare, hệ thống sẽ giấu địa chỉ IP thật của VPS đi và trả về địa chỉ IP của máy chủ biên Cloudflare (Anycast Edge) để đứng ra đỡ đòn DDoS và tăng tốc CDN giúp bạn. Lúc này, nếu website gặp lỗi (như các mã lỗi 521, 522, 526 hoặc lỗi vòng lặp chuyển hướng), bạn cần phân biệt rõ lỗi đang sinh ra ở tầng cấu hình SSL/Rules của Cloudflare hay nằm ở chính chiếc VPS gốc.

Cách bóc tách sắc bén nhất là dùng lệnh curl --resolve để đi vòng qua đám mây Proxy và gõ cửa trực tiếp máy chủ gốc bằng địa chỉ IP thật của VPS:

curl -I --resolve lab-cf02.localhost.vn:80:203.0.113.10 \
  http://lab-cf02.localhost.vn/

Bạn nhớ thay địa chỉ IP minh họa 203.0.113.10 bằng địa chỉ IP thật của VPS mình nhé. Lưu ý nhỏ: nếu bạn đã cấu hình tường lửa trên VPS theo trường phái bảo mật cao — chỉ cho phép dải IP của Cloudflare kết nối vào và chặn toàn bộ IP dân dụng khác — thì việc bạn ngồi ở nhà gõ lệnh curl --resolve thẳng vào IP gốc bị chặn lại là hoàn toàn đúng thiết kế bảo vệ. Hãy luôn nắm rõ chính sách tường lửa hiện tại của mình trước khi đọc kết quả.

Trong đợt kiểm tra thực tế lúc 23:33 ngày 30/09/2026, khi chúng tôi chạy curl --resolve từ máy tính cá nhân gọi thẳng tới IP gốc của máy chủ lab ở cổng 80, máy chủ trả về mã HTTP 301 chuyển hướng sang HTTPS; và khi gọi ở cổng 443 thì trả về đúng nội dung trang thử nghiệm cùng xác thực TLS thành công mỹ mãn (không dùng cờ -k).

Sơ đồ phương pháp so sánh hai luồng truy vấn độc lập (qua DNS/Proxy thông thường và gọi thẳng vào IP Origin qua --resolve) do đội ngũ localhost.vn biên soạn.

Tầng 4: Kiểm tra kết nối mạng, bắt tay TLS và chuỗi chuyển hướng HTTP

curl -I --connect-timeout 10 http://lab-cf02.localhost.vn/
curl -I --connect-timeout 10 https://lab-cf02.localhost.vn/

Ở tầng thứ tư này, phản hồi từ hai câu lệnh curl bên trên sẽ chỉ điểm chính xác vấn đề: nếu bị Timeout, hãy quay lại kiểm tra IP đích, đường định tuyến và tường lửa UFW / Cloud Firewall; nếu bị Connection refused, hãy kiểm tra xem NGINX đã bật và lắng nghe đúng cổng chưa. Nếu vấp phải lỗi chứng chỉ SSL/TLS không khớp tên miền hoặc hết hạn, hãy xử lý bằng Certbot ngay trên máy chủ chứ việc đi sửa lại bản ghi A trên bảng DNS hoàn toàn không làm chứng chỉ tự mới lại được!

Một ca bệnh “kinh điển của kinh điển” khi chuyển nhà cho WordPress: bản ghi DNS đã trỏ đúng về VPS mới, Server Block NGINX cũng đã cấu hình chuẩn không cần chỉnh, nhưng hễ gõ tên miền mới vào trình duyệt là nó lại tự động nhảy vọt về tên miền cũ hoặc nhảy sang một đường dẫn kỳ quặc! Thủ phạm lúc này không phải DNS, mà do hai giá trị siteurl và home lưu trong bảng wp_options của cơ sở dữ liệu WordPress vẫn đang giữ URL cũ, khiến mã nguồn PHP tự phát lệnh chuyển hướng 301/302. Để bắt tận tay thủ phạm này, bạn chỉ cần đọc dòng Location: trong kết quả curl -I, hoặc chạy curl -IL --max-redirs 5 để nhìn rõ từng bước nhảy. Tương tự, nếu gặp lỗi Too many redirects (lặp vô tận giữa HTTP và HTTPS), hãy kiểm tra ngay chế độ SSL trên Cloudflare: khi VPS gốc đã có chứng chỉ SSL và bật ép chuyển hướng sang HTTPS, bạn phải chọn chế độ Full (strict) trên Cloudflare chứ nếu để Flexible thì Cloudflare cứ gọi HTTP vào VPS còn VPS lại đuổi 301 ra HTTPS, tạo thành vòng lặp bất tận!

Tầng 5: Định tuyến Server Block trong NGINX và nội dung ứng dụng

Khi gói tin đã vượt qua mọi chặng đường xa xôi để vào tới tận VPS mà trang web hiện ra vẫn không đúng ý, chúng ta sẽ khám nghiệm trực tiếp trên máy chủ bằng bộ tứ câu lệnh sau:

sudo nginx -t
sudo ss -ltnp '( sport = :80 or sport = :443 )'
sudo tail -n 30 /var/log/nginx/lab-cf02.access.log
sudo tail -n 30 /var/log/nginx/lab-cf02.error.log

Hãy mở đúng đường dẫn file log đã khai báo trong khối server của website đó, sau đó thử gõ một truy vấn có đuôi đặc biệt (ví dụ curl -I https://lab-cf02.localhost.vn/?kiem-tra-123) rồi nhìn xem dòng truy vấn đó có hiện lên trong access.log của site hay không. Nếu hoàn toàn không thấy bóng dáng request đâu trong log của site mới mà nó lại chui tọt vào file /var/log/nginx/access.log chung, nghĩa là chỉ thị server_name của bạn chưa khớp với Host header nên NGINX đã đẩy khách sang khối default_server. Còn nếu request đã vào đúng log của site mà báo lỗi 403/404, hãy rà soát lại đường dẫn root, chỉ thị index và quyền đọc file.

Trong những ca phức tạp có nhiều file cấu hình chồng chéo, lệnh sudo nginx -T (chữ T viết hoa) là vũ khí tối thượng vì nó sẽ in toàn bộ cấu hình tổng hợp mà NGINX đang thực sự nạp trong bộ nhớ ra màn hình. Tuy nhiên, vì đầu ra của nginx -T rất dài và chứa toàn bộ cấu trúc các website trên máy, bạn chỉ nên tự đọc trên Terminal hoặc trích xuất đúng đoạn liên quan sau khi đã ẩn các đường dẫn nhạy cảm. Và luôn nhớ quy trình bất di bất dịch: sao lưu file trước khi sửa → chạy sudo nginx -t kiểm tra cú pháp → chạy sudo systemctl reload nginx.

Số liệu thực nghiệm bóc tách lỗi tại tầng NGINX trên LAB-CF-02

Vào lúc 03:31:12 đến 03:31:13 ngày 01/10/2026 (giờ Việt Nam), chúng tôi đã thực hiện một bài kiểm tra bóc tách lỗi định tuyến của NGINX 1.24.0 (Ubuntu) thông qua cổng lắng nghe nội bộ 127.0.0.1:8082 với bộ file HTML và cấu hình tách biệt hoàn toàn. Các tên miền đuôi .test được truyền qua Host header để chứng minh cách phân biệt lỗi từng lớp mà không cần đụng tới DNS công khai hay website WordPress đang vận hành:

Như bảng số liệu trên minh họa rất rõ: cùng là một thông báo lỗi trên trình duyệt (như 404 hay 403), nhưng khi kết hợp đọc mã phản hồi HTTP cùng với nội dung ghi trong access.log và error.log, chúng ta chỉ mất vài giây để biết chính xác lỗi do gõ sai tên miền, thiếu file hay sai phân quyền.

Sau khi hoàn tất bài đo, toàn bộ cấu hình và symlink thử nghiệm trên cổng 8082 đã được tháo gỡ, kiểm tra nginx -t và reload dịch vụ an toàn; toàn bộ 18 mục cấu hình sẵn có trên máy chủ đều khớp tuyệt đối với trạng thái ban đầu và các website WordPress hiện hữu hoạt động ổn định xuyên suốt.

Ảnh chụp màn hình đợt thực nghiệm trực tiếp lúc 09:45 ngày 01/10

Giao diện console dưới đây ghi lại đợt chạy kiểm tra trực tiếp vào lúc 09:45:42 (UTC+7) ngày 01/10/2026, tái hiện trọn vẹn kịch bản phân luồng và khoanh vùng lỗi trên cổng nội bộ 127.0.0.1:8082:

Ảnh chụp console thực tế ngày 01/10/2026 bắt đầu lúc 09:45:42 giờ Việt Nam (dấu thời gian trong log hiển thị theo chuẩn UTC, tương ứng 09:45:43–44 UTC+7). Vùng hiển thị console được giữ nguyên vẹn pixel và gắn thêm thanh logo ở chân ảnh. Bấm vào ảnh để mở kích thước đầy đủ.

Kết quả trong ảnh một lần nữa xác nhận quy trình chuẩn: hai tên miền hợp lệ trả về mã 200 (105 byte HTML), tên miền lạ hoặc đường dẫn thiếu trả về mã 404, khóa quyền file về 000 trả về mã 403 và khi trả về quyền 644 thì nhận lại mã 200 ngay lập tức; đồng thời cả website nguồn HTTPS lẫn trang clone đều duy trì trạng thái 200 OK ổn định (tls_verify=0).

Biểu mẫu ghi chép nhật ký khi điều tra sự cố tên miền

Việc điền nhanh 6 dòng vào bảng trên giúp bạn giữ được cái đầu lạnh và làm việc dựa trên dữ liệu thực tế thay vì dựa vào trí nhớ mang máng. Hơn nữa, nếu bạn cần gửi phiếu yêu cầu hỗ trợ kỹ thuật cho nhà cung cấp VPS hoặc nhà đăng ký tên miền, một bảng thông số rõ ràng như thế này sẽ giúp kỹ sư trực ca bắt tay vào xử lý ngay lập tức thay vì phải hỏi đi hỏi lại những câu cơ bản.

Sơ đồ nguyên tắc kỷ luật “Mỗi lần chỉ thay đổi một biến số” khi gỡ lỗi hệ thống do đội ngũ localhost.vn biên soạn.

Nguyên tắc hoàn tác (Rollback) và câu hỏi thường gặp

Nguyên tắc vàng khi rollback là: sửa ở tầng nào thì hoàn tác ở đúng tầng đó. Nếu vừa đổi bản ghi DNS hay bật nhầm chế độ Proxy mà thấy lỗi, hãy trả lại đúng bản ghi cũ; nếu vừa sửa file cấu hình NGINX, hãy khôi phục từ bản sao lưu rồi chạy nginx -t và reload. Một lưu ý cực kỳ quan trọng đối với các website thương mại điện tử hoặc trang có người dùng tương tác: nếu sau khi trỏ sang VPS mới, khách hàng đã bắt đầu đặt đơn hàng hoặc bình luận trên cơ sở dữ liệu mới, bạn phải cân nhắc kỹ phương án đồng bộ dữ liệu phát sinh đó trước khi quyết định trỏ ngược DNS về máy chủ cũ để tránh mất đơn hàng của khách!

Hỏi: Nghe người ta bảo trỏ tên miền xong cứ đi ngủ chờ đủ 24–48 giờ là khắc tự lên, có đúng không?
Đáp: Chỉ đúng trong trường hợp duy nhất là bạn đã cấu hình đúng 100% mọi thứ và lỗi chỉ do bộ nhớ đệm (TTL) cũ quá dài chưa kịp hết hạn! Còn nếu bạn gõ sai địa chỉ IP trong bản ghi A, quên mở cổng 80/443 trên tường lửa hay viết sai server_name trong NGINX, thì bạn có chờ đến… sang năm nó cũng không thể tự đúng lên được.

Hỏi: Bấm nút “Purge Everything” (Xóa toàn bộ cache) trên Cloudflare có giúp cập nhật bản ghi DNS nhanh hơn không?
Đáp: Không nhé! Nút Purge Cache trong mục Caching của Cloudflare là để xóa bộ nhớ đệm của các file tĩnh giao thức HTTP (như ảnh, CSS, JS), hoàn toàn không liên quan gì đến bộ nhớ đệm phân giải tên miền (DNS Cache) trên máy chủ của các nhà mạng viễn thông.

Hỏi: Khi nào thì tôi nên dừng việc chẩn đoán lại?
Đáp: Hãy dừng việc mò mẫm ngay khi bạn tìm thấy bằng chứng lỗi đầu tiên ở một tầng cụ thể (ví dụ dig báo sai IP, hoặc nginx -t báo lỗi cú pháp). Hãy tập trung sửa dứt điểm điểm gãy đó, chạy lại đúng câu lệnh vừa rồi để xác nhận nó đã xanh, rồi mới bước sang kiểm tra tầng kế tiếp.

Tài liệu tham khảo và bước tiếp theo

Các tài liệu kỹ thuật chính thức được đối chiếu phục vụ bài viết vào ngày 01/10/2026 bao gồm: Cloudflare Docs: Manage DNS records, NGINX Docs: How nginx processes a request và Cloudflare Docs: Full (strict) SSL/TLS encryption mode.

Bạn có thể theo dõi toàn bộ chuỗi bài tại lộ trình cài đặt WordPress trên VPS từ A đến Z, hoặc xem lại bài liền trước: Kiểm tra cổng 80/443 và Cloud Firewall (Bài 34). Khi đường truyền từ tên miền đến NGINX đã thông suốt hoàn toàn, mời bạn bước sang Phần E (Bài 36): Cài đặt PHP và MariaDB trên Ubuntu, kiểm tra phiên bản, dịch vụ và Unix socket để chuẩn bị nền tảng chạy mã nguồn động cho WordPress.