Cài WordPress trên VPS từ A đến màn hình đăng nhập: Ghép nối NGINX, PHP-FPM và MariaDB chuẩn chỉnh

Phạm vi thực hành: Quy trình cài đặt mới hoàn toàn trên Ubuntu 24.04 với tên miền thử nghiệm thuộc quyền quản lý trực tiếp. Bản WordPress gốc trên máy chủ LAB-CF-02 vốn được dựng từ trước bằng WP-CLI. Đến ngày 02/10/2026, chúng tôi thực hiện thêm một đợt thực nghiệm độc lập trên thư mục và database mới tinh để chạy trọn vẹn trình cài đặt qua trình duyệt (Web Installer), đăng nhập vào Dashboard và nghiệm thu giao diện khách truy cập. Môi trường thử nghiệm đó đã được dọn dẹp sạch sẽ ngay sau khi hoàn tất; tuyệt đối không mang các thao tác chép đè mã nguồn, khởi tạo DB hay mở lại installer áp dụng lên những website đang vận hành có dữ liệu thật.

Sau mấy bài miệt mài lắp từng cụm “động cơ” từ web server cho tới cơ sở dữ liệu, bài cài WordPress trên VPS hôm nay chính là lúc anh em mình ráp toàn bộ linh kiện LEMP stack lại thành một website hoàn chỉnh, rồi nghiệm thu từ màn hình đăng nhập HTTPS, giao diện khách cho tới vị trí từng file và bảng dữ liệu trong database. Để bạn dễ theo dõi mà không bị lẫn lộn giữa môi trường có sẵn và môi trường cài mới, nhật ký thực nghiệm được chia làm ba mốc tách biệt: xác minh form đăng nhập ngày 01/10, khảo sát màn hình cấu hình database lúc 11:01 ngày 02/10, và chạy trọn vẹn trình cài đặt trên trình duyệt lúc 16:07 cùng ngày để vào tận Dashboard, lưu cấu hình Permalink cũng như mở trang khách. Riêng phần upload ảnh trong Media Library được nghiệm thu bổ sung trên máy chủ LAB03 vào ngày 05/10 ở cuối bài.

Chuẩn bị trước khi tải WordPress

Trước khi đụng tay vào tải mã nguồn, hãy đảm bảo VPS của bạn đã có NGINX đang phục vụ ngon lành tên miền lab-cf02.localhost.vn, dịch vụ PHP 8.3 FPM và MariaDB 10.11 đều đang chạy ổn định, đồng thời bạn đang thao tác bằng một tài khoản quản trị có quyền sudo riêng biệt chứ không phải ôm khư khư tài khoản root. Trong khuôn khổ bài này, chúng ta sẽ đi qua đầy đủ các bước tạo database/user và lên cấu hình wp-config.php cho WordPress; còn những góc khuất chuyên sâu hơn về cách cô lập quyền truy cập và bảo vệ chuỗi bí mật (secret) sẽ được mổ xẻ kỹ ở bài 38 và 39.

Nguyên tắc sống còn: Bọc HTTPS trước khi gõ bất kỳ mật khẩu nào. Nhiều anh em vì nôn nóng muốn nhìn thấy giao diện WordPress nên cứ để nguyên HTTP trần mà chạy trình cài đặt — chẳng khác nào đọc to mật khẩu quản trị giữa quán cà phê đông người. Hãy chạy command -v certbot và apt-cache policy certbot python3-certbot-nginx để rà soát xem trên máy đã có sẵn Certbot chưa. Nếu trước đó Certbot đã được cài đặt qua apt, snap hoặc script tự động của nhà cung cấp hosting, hãy xác định rõ nguồn cài và lịch tự động gia hạn hiện hành, tuyệt đối không cài chồng chéo thêm bản khác kẻo hai tiến trình gia hạn đánh nhau. Với môi trường lab Ubuntu sạch sẽ, chúng ta thống nhất dùng gói apt đồng bộ với bài 43 và máy chủ LAB-CF-02. Đừng quên xác nhận bản ghi DNS A/AAAA đã trỏ chuẩn về IP gốc của VPS, cổng 80/443 đã mở thông thoáng trên tường lửa và HTTP đang phản hồi bình thường.

sudo apt update &&
  sudo apt install certbot python3-certbot-nginx &&
  /usr/bin/certbot --version

Khi gói cài đặt đã sẵn sàng, tiến hành yêu cầu cấp phát chứng chỉ SSL/TLS cho đúng tên miền của site:

sudo /usr/bin/certbot --nginx -d lab-cf02.localhost.vn &&
  sudo nginx -t &&
  curl --fail -I https://lab-cf02.localhost.vn/ &&
  sudo /usr/bin/certbot renew --dry-run

Hãy đọc kỹ các thông báo và điều khoản từ Certbot, đối chiếu chính xác tên miền rồi giữ nguyên phần cấu hình TLS mà công cụ tự động thêm vào NGINX. Chỉ chuyển sang bước tiếp theo khi lệnh curl xác thực chứng chỉ thành công mượt mà mà không cần dùng đến cờ -k (bỏ qua lỗi chứng chỉ). Phiên bản Certbot cài qua apt trên LAB-CF-02 được ghi nhận là 2.9.0 — đây là phiên bản thực tế tại thời điểm thực hành chứ không khẳng định là bản mới nhất từ upstream. Cách giám sát tiến trình tự động gia hạn chứng chỉ sẽ được bàn kỹ ở bài 43. Bạn cũng có thể tham khảo thêm tại Tài liệu sử dụng Certbot.

Tiếp theo, hãy sao lưu file cấu hình NGINX và thư mục HTML tĩnh hiện tại ra một nơi an toàn nằm ngoài web root. Nếu thư mục đích đang chứa sẵn mã nguồn WordPress hoặc dữ liệu của một website đang chạy, hãy phanh gấp ngay lập tức! Quy trình cài mới dưới đây sinh ra cho một mặt bằng trống, tuyệt đối không dùng để chép đè lên site đang có dữ liệu.

Khóa cửa công trường để tránh khách không mời: Bạn có biết trên Internet có hàng vạn con bot ngày đêm quét tự động đường dẫn /wp-admin/install.php không? Nếu bạn vừa giải nén mã nguồn WordPress và tạo xong wp-config.php nhưng đi pha ly cà phê chưa kịp bấm cài đặt, kẻ xấu hoàn toàn có thể nhanh tay mở trang installer trước bạn và chiếm quyền admin trong một nốt nhạc. Vì vậy, trước khi chép mã WordPress vào web root, hãy dựng ngay một lớp rào chắn Basic Auth tạm thời cho khối server HTTPS của lab. Cài công cụ tạo file mật khẩu apache2-utils và thiết lập mật khẩu riêng tại dấu nhắc lệnh:

(
  sudo apt install apache2-utils || exit 1
  if sudo test -e /etc/nginx/lab-cf02.htpasswd ||
     sudo test -L /etc/nginx/lab-cf02.htpasswd; then
    printf '%s\n' 'Dung: file mat khau da ton tai, khong dung -c.' >&2
    exit 1
  fi
  sudo htpasswd -c /etc/nginx/lab-cf02.htpasswd labinstaller &&
    sudo chown root:www-data /etc/nginx/lab-cf02.htpasswd &&
    sudo chmod 640 /etc/nginx/lab-cf02.htpasswd
)

Lưu ý nhỏ nhưng cực kỳ quan trọng: cờ -c (create) chỉ được dùng duy nhất ở lần đầu tiên khởi tạo file mật khẩu mới, vì nếu dùng lại nó sẽ xóa sạch nội dung file cũ đang có. Tiếp đó, mở khối cấu hình server cổng 443 của lab và bổ sung hai dòng chỉ thị auth_basic "Lab installation"; cùng auth_basic_user_file /etc/nginx/lab-cf02.htpasswd;. Chạy lệnh sudo nginx -t && sudo systemctl reload nginx để áp dụng. Hãy thử nghiệm ngay: gọi URL HTTPS mà không truyền thông tin đăng nhập phải nhận về mã lỗi 401 Unauthorized, mở bằng trình duyệt phải bật hộp thoại hỏi mật khẩu, và truy cập HTTP thường phải tự động chuyển hướng sang cổng HTTPS đã được khóa bảo vệ. Hoàn tất trọn vẹn bước rào chắn này trước khi bung mã nguồn để đảm bảo không một ai ngoài bạn có thể chạm vào màn hình cài đặt. Xem thêm tài liệu chính thức tại NGINX Basic Auth.

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm tóm tắt quy trình chuẩn bị, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 1: tải bản phát hành chính thức

Trong phiên làm việc SSH của tài khoản triển khai (deploy user), hãy tải gói mã nguồn WordPress nguyên bản từ kho chính thức vào một thư mục tạm:

lab_work_dir=$(mktemp -d) &&
  cd "$lab_work_dir" &&
  curl --fail --location --proto '=https' --tlsv1.2 \
    https://wordpress.org/latest.tar.gz -o wordpress.tar.gz &&
  tar -tzf wordpress.tar.gz > archive-list.txt &&
  head -n 15 archive-list.txt &&
  tar -xzf wordpress.tar.gz

Nhờ chuỗi toán tử &&, nếu bất kỳ mắt xích nào từ việc tạo thư mục tạm, chuyển đường dẫn (cd), tải gói nén cho tới kiểm tra định dạng archive gặp trục trặc, toàn bộ chuỗi lệnh sẽ dừng lại ngay tức khắc. Hãy xử lý dứt điểm lỗi mạng hoặc ổ đĩa trước khi đi tiếp và chỉ giải nén khi gói tải về đã nguyên vẹn 100%. Do gói latest.tar.gz luôn tự động cập nhật theo từng đợt phát hành của WordPress, hãy kiểm tra số phiên bản thực tế bên trong file wordpress/wp-includes/version.php hoặc xem trong Dashboard sau khi cài xong, đừng bao giờ ghi chép số phiên bản vào sổ tay vận hành bằng cách đoán mò.

Trước khi đưa mã nguồn vào vị trí chính thức, hãy xác minh thật kỹ rằng thư mục đích là mặt bằng riêng của site lab. Hãy di dời các file HTML mẫu của bài trước sang thư mục sao lưu nằm ngoài web root; thư mục đích lúc này phải trống hoàn toàn (bao gồm cả các file ẩn bắt đầu bằng dấu chấm). Nếu phát hiện bất kỳ file lạ nào nằm sẵn ở đó, hãy dừng lại tìm hiểu nguồn gốc chứ đừng nhắm mắt xóa bừa cho qua chốt chặn. Khi mặt bằng đã sạch bóng, tiến hành chép mã nguồn vào đúng web root:

(
  [ "$(id -u)" -ne 0 ] &&
    [ -n "${lab_work_dir-}" ] &&
    [ -f "$lab_work_dir/wordpress/wp-load.php" ] &&
    [ -d /var/www/lab-cf02 ] && [ ! -L /var/www/lab-cf02 ] || exit 1
  first_entry=$(sudo find /var/www/lab-cf02 -mindepth 1 -maxdepth 1 -print -quit) || exit 1
  if [ -n "$first_entry" ]; then
    printf '%s\n' 'Dung: web root chua rong; giu file hien co va kiem lai.' >&2
    exit 1
  fi
  sudo cp -a "$lab_work_dir/wordpress/." /var/www/lab-cf02/ &&
    sudo chown -R "$(id -un)":www-data /var/www/lab-cf02 &&
    sudo find /var/www/lab-cf02 -type d -exec chmod 755 {} + &&
    sudo find /var/www/lab-cf02 -type f -exec chmod 644 {} +
)

Đoạn script bảo vệ phía trên sẽ lập tức từ chối chạy nếu phát hiện bên trong web root còn sót bất kỳ file hay thư mục ẩn nào — đây là chốt an toàn giúp bạn không bao giờ vô tình chép đè lên một website đang chạy. Lệnh id -un tự động lấy tên user triển khai của phiên làm việc hiện tại (và đoạn kiểm tra đầu tiên cũng chặn luôn trường hợp bạn lỡ tay chạy bằng root). Cặp dấu ngoặc đơn ( ... ) đóng vai trò gom toàn bộ lệnh vào một subshell riêng biệt, nhờ vậy nếu lệnh exit kích hoạt thì cũng chỉ thoát khỏi subshell chứ không làm văng mất cửa sổ terminal SSH của bạn. Lưu ý rằng việc gán quyền đệ quy ở đây chỉ thực hiện trên cây thư mục mới tinh vừa giải nén, trước khi chúng ta tạo file chứa mật khẩu. Quyền hạn riêng của wp-config.php sẽ được khóa chặt ở bước kế tiếp, và bài 40 sẽ phân tích chi tiết lý do vì sao tuyệt đối không được để tiến trình PHP có quyền sửa đổi mã nguồn core.

Bước 2: nối NGINX tới PHP-FPM

Bây giờ hãy mở lại file cấu hình server block của lab trong NGINX. Giữ nguyên các dòng cấu hình chứng chỉ SSL/TLS do Certbot sinh ra, chỉ thay thế phần điều hướng nội dung bằng cụm chỉ thị dưới đây. Lưu ý sửa trực tiếp trên khối cổng 443 hiện có, đừng tạo thêm một khối server lắng nghe cổng 443 trùng lặp kẻo NGINX báo lỗi xung đột:

root /var/www/lab-cf02;
index index.php index.html;

location / {
    try_files $uri $uri/ /index.php?$args;
}

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

location = /wp-config.php {
    deny all;
}

location ~ /\.(?!well-known) {
    deny all;
}

Hãy để ý thứ tự các khối location: quy tắc chặn thực thi file .php bên trong thư mục uploads bắt buộc phải nằm phía trên khối xử lý PHP tổng quát. Tại sao ư? Vì trong NGINX, các biểu thức chính quy (regex location) được ưu tiên khớp theo thứ tự xuất hiện từ trên xuống dưới; đặt chốt chặn ở trên sẽ ngăn chặn kịch bản kinh điển khi kẻ tấn công lách luật tải một webshell đuôi .php giả dạng hình ảnh lên thư mục media rồi gọi chạy trực tiếp. Đường dẫn fastcgi_pass cần trỏ đúng vào file Unix socket của PHP 8.3 FPM mà chúng ta đã xác minh ở bài 36. File cấu hình đính kèm snippets/fastcgi-php.conf là tiện ích có sẵn của gói NGINX trên Ubuntu; nếu bạn biên dịch NGINX từ mã nguồn hoặc dùng bản phân phối khác, hãy kiểm tra sự tồn tại của file này trước khi dùng.

sudo nginx -t && sudo systemctl reload nginx

Luôn giữ thói quen gõ nginx -t báo cú pháp chuẩn chỉ (syntax is ok) rồi mới reload dịch vụ. Sau khi reload, nếu bạn mở trình duyệt mà thấy nó tải tuột cả file mã nguồn PHP về máy thay vì hiển thị giao diện web, hãy lập tức ngắt kết nối công khai và sửa lại cấu hình FastCGI ngay. Khi PHP-FPM chưa thực thi đúng mã nguồn thì tuyệt đối chưa được điền mật khẩu vào file cấu hình kẻo phơi bày toàn bộ thông tin nhạy cảm dưới dạng văn bản thuần!

Bước 3: tạo cấu hình DB riêng

Mỗi website WordPress xứng đáng có một căn hộ riêng biệt trong cơ sở dữ liệu. Hãy chọn một tên database mới chỉ sử dụng chữ cái thường và chữ số (chẳng hạn sitebloglab), kèm theo một tài khoản user MariaDB mới và một chuỗi mật khẩu ngẫu nhiên thật dài lưu trong trình quản lý mật khẩu (Password Manager). Một kinh nghiệm xương máu với MariaDB/MySQL: ký tự gạch dưới _ và phần trăm % khi nằm trong tên database của câu lệnh GRANT có thể bị hiểu nhầm thành ký tự đại diện (wildcard) ngay cả khi bạn đã bọc trong dấu backtick! Nếu phải làm việc với database cũ trót đặt tên có dấu gạch dưới, bạn cần xem kỹ cách escape bằng dấu gạch chéo ngược ở bài 38 trước khi phân quyền; còn khi tạo mới thì cứ chữ thường liền mạch mà đặt cho lành, và nhớ đừng tự ý đổi tên DB của website đang chạy chỉ để giống với bài hướng dẫn. Toàn bộ các chữ viết hoa như TENDBDACHON, USER_DB_DA_CHON, MAT_KHAU_SINH_RIENG dưới đây chỉ là nhãn giữ chỗ — bạn phải thay bằng thông tin thật của mình. Hãy mở trình khách MariaDB kèm biến môi trường tắt ghi lịch sử câu lệnh bằng sudo env MYSQL_HISTFILE=/dev/null mariadb, chạy SHOW DATABASES; để chắc chắn không đụng chạm tới dữ liệu cũ, rồi thực thi:

CREATE DATABASE `TENDBDACHON`
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'USER_DB_DA_CHON'@'localhost'
  IDENTIFIED BY 'MAT_KHAU_SINH_RIENG';
GRANT ALL PRIVILEGES ON `TENDBDACHON`.*
  TO 'USER_DB_DA_CHON'@'localhost';
SHOW GRANTS FOR 'USER_DB_DA_CHON'@'localhost';

Bạn thấy đấy, chúng ta chỉ cấp quyền gói gọn trong phạm vi `TENDBDACHON`.* chứ tuyệt đối không hào phóng cấp quyền toàn cục *.*. Chuỗi mật khẩu đưa vào câu lệnh SQL phải đảm bảo đúng cú pháp chuỗi ký tự (string literal); nếu mật khẩu có chứa dấu nháy đơn thì phải escape cẩn thận, hoặc đơn giản nhất là tạo một chuỗi dài ngẫu nhiên gồm chữ cái và số để dán vào cho an toàn. Sau khi tạo xong, hãy thoát khỏi phiên quản trị MariaDB rồi tự kiểm tra lại bằng chính tài khoản vừa tạo: mariadb --user=USER_DB_DA_CHON --password TENDBDACHON. Gõ mật khẩu khi dấu nhắc hiện ra, chạy thử SELECT CURRENT_USER(), DATABASE(); để xác nhận đăng nhập thành công và nhớ đừng bao giờ chụp ảnh màn hình có dính mật khẩu thật.

Tiếp theo, vẫn từ tài khoản triển khai trên Linux, chúng ta chủ động khởi tạo file wp-config.php với quyền hạn chặt chẽ trước khi mở trình cài đặt trên web:

(
  cd /var/www/lab-cf02 || exit 1
  if [ -e wp-config.php ] || [ -L wp-config.php ]; then
    printf '%s\n' 'Dung: wp-config.php da ton tai, can kiem cau hinh hien tai.' >&2
    exit 1
  fi
  (umask 077; set -C; cat wp-config-sample.php > wp-config.php) &&
    chmod 640 wp-config.php &&
    sudo chgrp www-data wp-config.php &&
    nano wp-config.php
)

Nếu trên máy đã tồn tại sẵn file wp-config.php, đoạn lệnh sẽ dừng lại để bạn mở ra rà soát chứ không mù quáng ghi đè. Hãy mở file vừa tạo và điền các thông số DB_NAME, DB_USER, DB_PASSWORD từ kho lưu trữ mật khẩu của bạn; giữ DB_HOST là localhost vì PHP-FPM và MariaDB đang nằm chung trên một VPS. Giữ nguyên cấu hình bảng mã utf8mb4/utf8 theo chuẩn file mẫu. Đặc biệt, hãy truy cập WordPress salt generator qua giao thức HTTPS để lấy một bộ 8 khóa bảo mật (Salt Keys) mới tinh thay thế cho các dòng chữ mẫu put your unique phrase here, và tuyệt đối không đẩy file này lên Git công khai hay chụp ảnh khoe lên mạng. Nếu mật khẩu hay chuỗi khóa có ký tự đặc biệt, hãy kiểm tra kỹ dấu nháy trong cú pháp PHP.

Sau khi lưu file, hãy chạy ngay cặp lệnh kiểm tra: php -l /var/www/lab-cf02/wp-config.php để rà soát lỗi cú pháp PHP và sudo -u www-data test -r /var/www/lab-cf02/wp-config.php để chắc chắn rằng tiến trình PHP-FPM (chạy dưới user www-data) đọc được file cấu hình này. Chỉ khi cả hai lệnh đều trả về kết quả thành công thì mới bước tiếp. Xin nhắc lại ba điều cấm kỵ: không bao giờ dùng tài khoản root của database cho WordPress, không vứt các bản sao lưu kiểu wp-config.php.bak hay file .sql ngay trong thư mục web root, và không lưu mật khẩu ra file text. Bài 38 và 39 sẽ hướng dẫn bạn quy trình chuẩn để rà soát quyền truy cập cũng như đổi mật khẩu/salt định kỳ.

Cuối cùng, hãy tạo sẵn thư mục chứa hình ảnh tải lên (media uploads) với quyền ghi được khoanh vùng đúng chỗ:

sudo install -d -o "$(id -un)" -g www-data -m 2775 \
  /var/www/lab-cf02/wp-content/uploads

Với chế độ quyền 2775 (có bật bit setgid) và nhóm sở hữu là www-data, tiến trình PHP-FPM có thể thoải mái ghi ảnh vào thư mục uploads, trong khi tài khoản triển khai của bạn vẫn nắm quyền chủ sở hữu toàn bộ mã nguồn bên ngoài. Cách cài đặt thêm giao diện (theme) và tiện ích (plugin) một cách an toàn sẽ được trình bày ở bài 41. Nếu sau này vào Dashboard mà thấy WordPress bật bảng hỏi thông tin tài khoản FTP, bạn cũng đừng vì bực mình mà phang lệnh chmod -R 777 cho toàn bộ website nhé — làm vậy chẳng khác nào tháo tung cửa chính vì ổ khóa hơi rít!

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm tóm tắt quy trình cài đặt, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 4: chạy trình cài qua HTTPS

Giờ là khoảnh khắc tận hưởng thành quả: hãy mở trình duyệt, truy cập vào địa chỉ https://lab-cf02.localhost.vn/wp-admin/install.php, đăng nhập qua lớp cửa Basic Auth tạm thời và nhìn lên thanh địa chỉ để chắc chắn ổ khóa HTTPS hợp lệ trước khi gõ bất kỳ thông tin gì. Một mẹo chẩn đoán nhanh: vì ở Bước 3 chúng ta đã tạo sẵn file wp-config.php hoàn chỉnh, đáng lý trình cài đặt phải nhảy thẳng vào màn hình đặt tên website. Nếu trình cài đặt vẫn hiện bảng hỏi thông tin kết nối Database, hãy bình tĩnh quay ra terminal rà soát lại tên file, đường dẫn và quyền đọc của wp-config.php chứ đừng vội nhập lại mật khẩu DB trên trình duyệt khi chưa hiểu vì sao file cấu hình bị ngó lơ.

Tại màn hình thiết lập thông tin website, hãy chọn ngôn ngữ hiển thị, điền tiêu đề trang web, đặt một tên người dùng quản trị (username) thật riêng biệt — tránh xa những cái tên mời gọi hacker như admin hay administrator — cùng mật khẩu phức tạp sinh ra từ Password Manager. Hãy điền địa chỉ email quản trị mà bạn thực sự kiểm soát, tuyệt đối không lấy dữ liệu hay email của khách hàng thật đưa vào môi trường thử nghiệm. Với máy chủ lab, hãy tích chọn ô Ngăn chặn các công cụ tìm kiếm đánh chỉ mục trang web này (Discourage search engines from indexing this site), nhưng hãy luôn nhớ rằng tùy chọn đó chỉ là lời nhắn lịch sự qua thẻ meta/robots chứ không hề có tác dụng khóa mật khẩu ngăn người lạ truy cập.

Khi mọi thứ đã chuẩn, hãy bấm nút cài đặt đúng một lần rồi kiên nhẫn đợi vài giây. Nếu mạng chập chờn hoặc trình duyệt báo hết thời gian chờ (timeout), hãy mở log và kiểm tra các bảng trong database trước khi bấm lại, bởi rất có thể quá trình khởi tạo bảng đã chạy xong ở phía hậu trường rồi. Khi màn hình báo Success! hiện ra, hãy chuyển sang trang /wp-login.php và đăng nhập bằng tài khoản quản trị vừa khởi tạo.

Bước 5: xác nhận đúng kết quả

Chỉ sau khi tài khoản quản trị viên đã được khởi tạo xong xuôi và bạn đã đăng nhập thành công vào trong Dashboard, bạn mới nên gỡ bỏ hai dòng chỉ thị Basic Auth tạm thời trong file cấu hình vhost NGINX (nếu muốn mở cửa cho người dùng bên ngoài vào xem). Sau khi sửa file cấu hình, chạy lại sudo nginx -t && sudo systemctl reload nginx rồi mở trình duyệt ẩn danh để xác nhận. Ngược lại, nếu bạn muốn giữ nguyên môi trường lab này làm sân tập nội bộ dài hạn, cứ việc để nguyên lớp Basic Auth đó. Nguyên tắc bất di bất dịch là không bao giờ tháo rào chắn Basic Auth khi trình cài đặt chưa chạy xong.

Nhìn thấy trang Dashboard hiện lên vẫn chưa đủ để tuyên bố hoàn thành nhiệm vụ đâu nhé. Một kỹ sư cẩn thận sẽ luôn mở thêm một cửa sổ trình duyệt ẩn danh (chưa đăng nhập WordPress) để kiểm tra giao diện trang chủ của khách, ghi chép lại chính xác phiên bản WordPress đang chạy, vào mục Permalinks bấm lưu cấu hình đường dẫn tĩnh và thử tải lên một tấm ảnh nhỏ (không chứa thông tin nhạy cảm) để xem thư mục uploads có hoạt động trơn tru không. Bài 42 sắp tới sẽ cung cấp cho bạn danh sách kiểm tra toàn diện để bắt bệnh các lỗi thiếu thư viện PHP hoặc lệch quyền truy cập file.

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm tóm tắt các bước nghiệm thu sau cài đặt, không phải ảnh chụp màn hình trên máy chủ lab.

Hồ sơ bản cài đặt sẵn có và đợt rà soát ngày 01/10/2026

Trên máy chủ LAB-CF-02, bản WordPress gốc đang chạy vốn được khởi tạo từ đợt trước thông qua công cụ dòng lệnh WP-CLI. Nhật ký hệ thống ghi nhận phiên bản WordPress 7.1.2, mã băm kiểm tra tính toàn vẹn của bộ core (core checksums) khớp hoàn toàn, cấu trúc đường dẫn tĩnh đang đặt là /%postname%/ và file wp-config.php được khóa ở chế độ quyền 640. Tất nhiên, trạng thái cài sẵn bằng WP-CLI này chưa thể dùng làm minh chứng trực quan cho màn hình cài đặt qua trình duyệt hay lớp khóa Basic Auth nêu ở phần lý thuyết.

Vào lúc 03:42 ngày 01/10/2026 (giờ Việt Nam), đợt rà soát ở chế độ chỉ đọc (read-only) trên môi trường gốc này ghi nhận các thông số thực tế sau:

Đúng một phút sau, lúc 03:43 cùng ngày, trình duyệt Chrome từ máy trạm bên ngoài VPS đã truy cập vào địa chỉ HTTPS /wp-login.php, quan sát thấy rõ ô nhập tên người dùng, ô mật khẩu, nút Đăng nhập và bộ chọn ngôn ngữ Tiếng Việt. Ở lần mở nhanh lúc 03:43 này, chúng tôi chỉ quan sát biểu mẫu trống chứ chưa điền thông tin đăng nhập và chưa lưu ảnh chụp màn hình.

Đến 07:58:20 ngày 01/10/2026 (giờ Việt Nam), trình duyệt Chrome mở lại địa chỉ https://lab-cf02.localhost.vn/wp-login.php và ghi lại bức ảnh chụp giao diện thực tế ngay dưới đây. Cả hai ô tên người dùng và mật khẩu đều để trống hoàn toàn; không thực hiện thao tác đăng nhập nào trong bước này.

Ảnh chụp trang web thực tế lúc 07:58:20 ngày 01/10/2026 (giờ Việt Nam), đã cắt gọn vùng khung đăng nhập và đóng dấu logo ở chân ảnh nhưng giữ nguyên 100% điểm ảnh (pixel) gốc của vùng hiển thị. Bức ảnh này xác nhận biểu mẫu đăng nhập lên hình chuẩn xác qua HTTPS, nhưng tự thân nó chưa chứng minh việc đăng nhập vào Dashboard hay chạy trình cài đặt qua trình duyệt. Bấm vào ảnh để xem kích thước đầy đủ.

Lưu ý thêm: mã phản hồi 403 Forbidden tại đường dẫn install.php trong bảng trên là do quy tắc chặn chủ động trên cấu hình NGINX của máy lab tại thời điểm đó, chứ không phải hành vi mặc định của mọi bản WordPress nguyên bản. Ngoài ra, việc trang /wp-login.php hiển thị đẹp đẽ mới chỉ chứng minh NGINX và PHP-FPM đã render được trang đăng nhập, chứ chưa khẳng định mật khẩu khớp hay phiên làm việc trong Dashboard hoạt động trơn tru. Vì website gốc trên LAB-CF-02 đã đi vào vận hành ổn định, chúng tôi tuyệt đối không xóa đi cài lại chỉ để chụp vài tấm ảnh minh họa, mà tách hẳn sang hai đợt thực nghiệm độc lập ngày 02/10 dưới đây.

Hai màn hình chuẩn bị cấu hình và lớp khóa Basic Auth ngày 02/10/2026

Để bạn thấy rõ điều gì xảy ra khi mở trình cài đặt mà chưa tạo sẵn file wp-config.php, vào lúc 11:01 ngày 02/10/2026 (giờ Việt Nam), chúng tôi giải nén một thư mục mã nguồn WordPress 7.1.2 mới tinh (đã đối chiếu chuẩn mã băm checksum chính thức) và cấu hình một tiến trình NGINX tách biệt chỉ lắng nghe nội bộ tại địa chỉ loopback 127.0.0.1:8443 trên máy chủ LAB-CF-02. Một trình duyệt Chromium độc lập được kết nối qua đường hầm SSH port forwarding, vẫn xác thực chứng chỉ HTTPS đúng tên miền như bình thường, trong khi toàn bộ cấu hình và dữ liệu người dùng của website WordPress gốc trên máy chủ được giữ nguyên vẹn không một vết xước.

Kết quả thử nghiệm chốt chặn Basic Auth: Khi gửi yêu cầu HTTP mà không kèm thông tin xác thực, máy chủ lập tức trả về mã 401; gửi sai mật khẩu cũng nhận ngay mã 401; và chỉ khi cung cấp đúng mật khẩu mới nhận được mã 200 (cả ba lần kết nối đều vượt qua bước xác thực chứng chỉ TLS ngon lành). Như vậy lớp rào chắn đã hoạt động đúng thiết kế cả khi đo bằng công cụ dòng lệnh lẫn khi mở trên trình duyệt. Hai bức ảnh dưới đây chụp giao diện trang web ngay sau khi đã đi qua cổng xác thực Basic Auth (không chụp hộp thoại nhập mật khẩu của trình duyệt). Mật khẩu tạm thời phục vụ bài test cũng được hủy bỏ ngay sau khi kết thúc phiên.

Ảnh chụp trình duyệt Chromium thực tế ngày 02/10/2026 sau khi vượt qua lớp Basic Auth. Đây chính là màn hình chào hỏi sẽ xuất hiện nếu bạn mở trình duyệt khi thư mục web chưa có file wp-config.php. Vùng nội dung giữ nguyên từng điểm ảnh, chân ảnh ghép thêm logo localhost.vn; bấm vào ảnh để xem bản lớn.

Khi bấm vào nút Let’s go! trên màn hình đó, WordPress sẽ đưa bạn tới biểu mẫu gồm 5 ô nhập liệu quen thuộc: Database Name, Username, Password, Database Host và Table Prefix. Những chữ wordpress, username, password nằm sẵn trong ô chỉ là văn bản gợi ý (placeholder) của giao diện chứ không phải thông tin tài khoản của máy lab, còn localhost và wp_ là giá trị mặc định. Nếu trong thực tế bạn đi theo nhánh cấu hình qua giao diện web này, hãy điền thông tin database và tài khoản riêng đã tạo ở Bước 3 chứ đừng bao giờ để nguyên mấy chữ gợi ý đó nhé.

Ảnh chụp thực tế trong cùng đợt thực nghiệm lúc 11:01, khi chưa điền thông tin database và chưa bấm nút Submit. Chúng tôi cũng kiểm tra thêm trên khung nhìn di động (viewport rộng 390px) và xác nhận giao diện co giãn tốt, không bị tràn chiều ngang.

Tại sao lại cần phân biệt rõ hai nhánh này? Trong phần hướng dẫn chính ở Bước 3, chúng tôi khuyên bạn chủ động tạo sẵn file wp-config.php từ dòng lệnh kèm quyền 640 chặt chẽ trước khi mở trình duyệt — làm theo cách đó thì bạn sẽ đi thẳng tới màn hình đặt tên website chứ không gặp hai màn hình ở trên. Tuy nhiên, việc chụp lại hai màn hình này sẽ giúp bạn nhận diện ngay tình huống thực tế: nếu bạn đinh ninh mình đã tạo wp-config.php rồi mà mở trình duyệt lên vẫn thấy nút Let’s go!, nghĩa là bạn đã đặt sai tên file, đặt nhầm thư mục hoặc quên cấp quyền đọc cho www-data! Tuyệt đối đừng xóa file wp-config.php chuẩn chỉnh bạn đã tạo chỉ để nhìn thấy hai bức ảnh này.

Đợt khảo sát lúc 11:01 được giới hạn chỉ nhận phương thức GET/HEAD và dừng lại đúng ở màn hình biểu mẫu trống: không khởi tạo database, không tạo tài khoản WordPress và không bấm chạy cài đặt. Ngay sau khi chụp xong, tiến trình NGINX nội bộ được tắt, cổng 8443 đóng lại, thư mục mã nguồn trống cùng file Basic Auth tạm thời đều được dọn sạch, đồng thời đối chiếu lại hai website WordPress đang có trên máy chủ để đảm bảo mọi cấu hình và danh sách người dùng giữ nguyên 100%. Toàn bộ quá trình cài đặt mới hoàn chỉnh qua trình duyệt được thực hiện trong đợt thực nghiệm độc lập lúc 16:07 ngay phần tiếp theo.

Thực nghiệm cài mới trọn vẹn qua trình duyệt ngày 02/10/2026

Trong khung giờ từ 16:07:34 đến 16:07:53 (giờ Việt Nam) ngày 02/10/2026, chúng tôi dựng một môi trường WordPress 7.1.2 (bản tiếng Anh en_US) hoàn toàn mới nằm trong thư mục độc lập và kết nối tới một database mới tinh trên máy chủ LAB-CF-02. Đây là đợt chạy thực tế trang install.php từ đầu đến cuối thông qua trình duyệt web, tách biệt hoàn toàn với bản cài sẵn bằng WP-CLI trước đó. Gói mã nguồn được tải trực tiếp từ kho lưu trữ chính thức, giải nén và đối chiếu mã băm checksum trước khi khởi tạo cơ sở dữ liệu. Tài khoản database mới chỉ được cấp quyền gói gọn trên đúng schema mới này và không có quyền GRANT OPTION.

Đợt thực nghiệm này bám sát đúng nhánh khuyến nghị trong bài: chuẩn bị sẵn file wp-config.php từ file mẫu ở tầng hệ điều hành trước khi mở trình cài đặt trên trình duyệt. Toàn bộ mật khẩu DB, khóa Salt và nội dung chi tiết bên trong file cấu hình được bảo mật tuyệt đối, không xuất hiện trên bất kỳ bức ảnh chụp nào. Tiến trình NGINX riêng biệt lắng nghe HTTPS trên địa chỉ loopback cổng 8443 và kết nối với trình duyệt Chromium qua đường hầm SSH (chứng chỉ số vẫn được xác thực khớp đúng tên miền). Do đó, hậu tố :8443 xuất hiện trên thanh địa chỉ hoặc đường dẫn trong ảnh chỉ là cổng nội bộ của môi trường thử nghiệm, còn website thực tế của bạn sẽ chạy trên cổng HTTPS 443 tiêu chuẩn.

Ảnh chụp thực tế ngày 02/10 trong đợt thực nghiệm 16:07. Ảnh đã được cắt gọn vùng thông báo, giữ nguyên điểm ảnh gốc và đính kèm logo ở chân ảnh. Dòng chữ “Your chosen password” là thông báo mặc định của WordPress khi bạn tự đặt mật khẩu chứ không hiển thị chuỗi mật khẩu thật. Tài khoản quản trị tạm thời trong ảnh cũng đã được xóa bỏ cùng môi trường thử nghiệm.

Biểu mẫu đăng nhập trống được ghi hình ngay trước khi điền thông tin tài khoản quản trị. Hãy luôn cất giữ mật khẩu trong trình quản lý mật khẩu chuyên dụng, đừng bao giờ để lộ thông tin nhạy cảm trong tài liệu hay ảnh chụp hướng dẫn.

Tài khoản quản trị mới đã bước vào bên trong Dashboard WordPress 7.1.2. Lưu ý rằng việc vào được trang tổng quan này hay thấy các hộp thông tin Site Health/News đang tải mới chỉ là bước khởi đầu, chưa đồng nghĩa với việc website đã sẵn sàng chịu tải ngoài môi trường production.

Màn hình Permalink Settings sau khi chuyển sang chế độ Post name và lưu lại. Để chắc chắn chỉ thị try_files của NGINX phối hợp ăn ý với cấu hình này, chúng tôi đã dùng một phiên trình duyệt khách mở trực tiếp bài viết mẫu tại đường dẫn /hello-world/ và xác nhận trang phản hồi HTTP 200.

Giao diện trang chủ hiển thị trên khung nhìn trình duyệt mô phỏng màn hình di động rộng 390 pixel, hiển thị rõ bài viết Hello world! và không bị vỡ khung ngang.

Trong suốt quá trình cài đặt thử nghiệm, chúng tôi sử dụng địa chỉ email có tên miền .invalid kết hợp với cơ chế chặn gửi thư ra ngoài ở tầng PHP để tránh phát sinh email rác. Do đó, đợt thực nghiệm này không bao gồm việc kiểm tra nhận thư điện tử thực tế. Khi dựng website thật, bạn bắt buộc phải dùng địa chỉ email đang hoạt động của mình và cấu hình/nghiệm thu luồng gửi nhận email cẩn thận trước ngày ra mắt.

Ngay sau khi hoàn tất bài test, kịch bản tự động đã xác nhận trạng thái cài đặt và cờ noindex, rồi tiến hành thu dọn sạch sẽ database tạm, user database tạm, thư mục mã nguồn WordPress vừa dựng cùng các file cấu hình/mật khẩu Basic Auth. Tiến trình NGINX cổng 8443 dừng hoạt động, đường hầm SSH và trình duyệt đóng lại, trả máy chủ LAB-CF-02 về trạng thái ban đầu với hai website gốc nguyên vẹn. Tất nhiên, quy trình xóa sổ gọn lẹ này chỉ áp dụng cho môi trường thử nghiệm vừa tạo xong, tuyệt đối không áp dụng cho website đang có dữ liệu cần bảo tồn.

Điểm cần bổ sung: Ở đợt chạy lúc 16:07 trên LAB-CF-02, mặc dù biểu mẫu upload ảnh báo thành công và tạo được bản ghi trong Media Library, khung hình thu nhỏ (thumbnail) trên giao diện chưa kịp tải xong hoàn chỉnh tại thời điểm chụp. Một kỹ sư nghiêm túc sẽ không lấy bức ảnh thumbnail còn đang chờ tải đó làm bằng chứng nghiệm thu! Vì vậy, chúng tôi đã thực hiện thêm một đợt kiểm chứng chuyên sâu riêng cho Media Library trên máy chủ LAB03 vào ngày 05/10 ngay dưới đây.

Nghiệm thu bổ sung Media Library trên LAB03 — 05/10/2026

Vào lúc 08:51 ngày 05/10/2026 (giờ Việt Nam), một bản WordPress 7.1.2 độc lập trên máy chủ LAB03 được khởi tạo riêng để nghiệm thu trọn vẹn khâu tải và hiển thị hình ảnh trong Media Library. Bộ mã nguồn được xác minh mã băm checksum chính thức; cơ sở dữ liệu, tài khoản quản trị và thư mục web được tạo tách biệt rồi dọn dẹp sạch sau khi hoàn tất.

Trình duyệt Chromium kết nối vào cổng nội bộ 127.0.0.1:8443 thông qua SSH tunnel, đi qua lớp khóa Basic Auth. Vì cổng này không mở ra Internet công cộng nên mục tiêu của đợt chạy này tập trung hoàn toàn vào việc nghiệm thu tính năng xử lý file media và hiển thị giao diện thư viện ảnh của WordPress.

Sau khi đăng nhập quản trị, chúng tôi tải lên một file ảnh PNG logo kích thước 220 × 30 pixel thông qua giao diện Media Library. Kịch bản nghiệm thu chỉ chụp màn hình khi trình duyệt xác nhận phần tử ảnh thu nhỏ (thumbnail) đã giải mã xong hoàn toàn (thuộc tính DOM complete=true và chiều rộng tự nhiên naturalWidth > 0).

Ở bài test truyền tải tệp tin này, ô Văn bản thay thế (Alternative Text) được để trống, còn khi bạn biên tập bài viết thực tế trên website thì hãy nhớ điền mô tả Alt đầy đủ theo hướng dẫn ở bài 42 (toàn bộ hình ảnh xuất bản trong bài viết này của chúng tôi đều đã được gắn thuộc tính alt chi tiết). Nhờ đối chiếu tận gốc mã băm SHA-256 khi tải ngược file ảnh về từ HTTP, chúng ta có thể khẳng định chắc nịch rằng luồng ghi đĩa của PHP-FPM và luồng phục vụ file tĩnh của NGINX đã hoạt động hoàn hảo tới từng byte.

Ngay sau khi lưu xong bằng chứng, trình duyệt và đường hầm SSH được đóng lại, tiến trình NGINX loopback cùng database, tài khoản tạm và thư mục thử nghiệm trên LAB03 đều được dọn dẹp sạch sẽ, giữ nguyên các dịch vụ nền NGINX/PHP-FPM/MariaDB cho những bài thực hành tiếp theo.

Phương án hoàn nguyên (Rollback) và câu hỏi thường gặp

Trong trường hợp bạn đang làm nháp trên môi trường mới mà muốn khôi phục lại hiện trạng ban đầu (khi chưa có bất kỳ bài viết hay dữ liệu nào cần giữ), bạn chỉ việc trả lại file cấu hình vhost NGINX cùng thư mục HTML tĩnh từ bản sao lưu sau khi đã kiểm tra cú pháp. Hãy giữ nguyên thư mục WordPress và database vừa tạo thêm một thời gian để phục vụ việc tìm hiểu nguyên nhân lỗi trước khi quyết định xóa hẳn. Ngược lại, nếu website đã có bài viết, hình ảnh hoặc tài khoản người dùng thật, hãy sao lưu trọn vẹn cả mã nguồn lẫn database trước khi thực hiện bất kỳ thao tác hoàn nguyên nào — và tuyệt đối không bao giờ gõ lệnh xóa database bằng cách đoán mò tên.

Cài WordPress theo bài này có bắt buộc phải dùng WP-CLI không? Hoàn toàn không bắt buộc. Quy trình hướng dẫn ở trên sử dụng trình cài đặt trực quan ngay trên trình duyệt web. Công cụ dòng lệnh WP-CLI sẽ phát huy sức mạnh ở các bài quản trị nâng cao phía sau (và khi dùng cũng cần tải từ nguồn chính thức của dự án WordPress).

Vừa cài đặt xong đã nên tắt tùy chọn chặn công cụ tìm kiếm (noindex) chưa? Với môi trường thử nghiệm (lab) thì câu trả lời là chưa. Ngay cả với website dự kiến chạy thật, bạn cũng chỉ nên mở cửa cho Google lập chỉ mục sau khi đã lên xong nội dung cơ bản, cấu hình biểu mẫu liên hệ, thiết lập lịch sao lưu tự động và hoàn tất danh sách kiểm tra trước giờ ra mắt (pre-launch checklist).

Những bằng chứng nào nên lưu vào sổ tay bàn giao? Hãy lưu lại số phiên bản WordPress, bản sao cấu hình NGINX/PHP đã lược bỏ thông tin nhạy cảm, cùng ảnh chụp màn hình đăng nhập HTTPS và trang Dashboard. Tuyệt đối không chụp ảnh chứa mật khẩu hoặc nội dung nguyên văn của file wp-config.php.

Nguồn tham khảo và bước tiếp theo

Tài liệu chính thức từ WordPress: hướng dẫn cài đặt và NGINX: Basic Auth đã được đội ngũ rà soát, đối chiếu lại vào ngày 02/10/2026. Các tài liệu nền tảng được đối chiếu ngày 30/09/2026 bao gồm WordPress: yêu cầu hệ thống, WordPress: gia cố bảo mật (Hardening) và NGINX: hướng dẫn FastCGI cơ bản. Các kịch bản xử lý sự cố và biểu mẫu biên bản nghiệm thu trong bài do đội ngũ kỹ thuật biên soạn riêng cho chuỗi bài thực hành này.

Xem toàn bộ lộ trình WordPress trên VPS. Bài trước: Cài PHP và MariaDB: phiên bản, service và kiểm tra. Bài tiếp theo: Tạo database và user riêng cho WordPress.