Cấu hình wp-config.php chuẩn bảo mật: Giữ kín mật khẩu DB, khóa Salt Keys và quyền 640

Phạm vi thực hành: Hệ điều hành Ubuntu 24.04 LTS trên máy chủ VPS thử nghiệm riêng biệt với tên miền lab lab-cf02.localhost.vn. Chỉ thao tác trên hạ tầng do chính bạn quản lý. Phần biên bản cuối bài ghi lại đợt rà soát file cấu hình đang chạy lúc 23:01 ngày 30/09/2026 (chỉ trích xuất trạng thái mã thoát và biến logic boolean để tuyệt đối không làm lộ chuỗi bí mật). Đợt thực nghiệm lúc 04:35 ngày 01/10/2026 kiểm chứng cơ chế chốt chặn (guard) khi tạo file trong thư mục nháp, và đợt lúc 10:57 cùng ngày thử nghiệm thay đổi rồi hoàn nguyên một hằng số không nhạy cảm trên bản clone mà không đụng chạm tới mật khẩu DB hay Salt Keys của site chính.

Trong thế giới WordPress, file wp-config.php chẳng khác nào cuốn sổ tay ghi đầy đủ mật mã két sắt: từ tên cơ sở dữ liệu, tài khoản, mật khẩu đăng nhập MariaDB cho tới bộ khóa mã hóa phiên làm việc (Salt Keys). Nghịch lý nằm ở chỗ: tiến trình PHP-FPM trên máy chủ bắt buộc phải đọc được file này mỗi khi có khách truy cập, nhưng người lạ trên Internet, kho chứa mã nguồn Git, ảnh chụp màn hình hướng dẫn hay các file nén sao lưu bỏ quên trong thư mục web lại tuyệt đối không được phép nhìn thấy dù chỉ một dòng của nó. Bài viết hôm nay sẽ hướng dẫn bạn cách khởi tạo wp-config.php từ bản mẫu, thiết lập quyền 640 chuẩn chỉnh và nghiệm thu kết quả mà không bao giờ làm phơi bày mật khẩu ra màn hình.

Nếu bạn đã hoàn tất cài đặt từ bài 37

Nếu bạn đang đi tuần tự từ bài 37 sang đây, website của bạn đã có sẵn file wp-config.php với thông tin kết nối DB và bộ Salt Keys riêng đang hoạt động ổn định. Lời khuyên chân thành: Hãy giữ nguyên file cấu hình và cơ sở dữ liệu đang chạy! Bạn chỉ cần đối chiếu lại thông tin trong kho lưu trữ mật khẩu của mình, xem xét bổ sung hằng số khóa trình sửa file ở Bước 4 nếu cần, rồi nhảy thẳng xuống Bước 5 để chạy lệnh rà soát cú pháp và quyền truy cập file. Tuyệt đối đừng xóa file đang chạy đi tạo lại, đừng chép đè mấy dòng chữ mẫu viết hoa vào ô mật khẩu và cũng đừng ngứa tay đổi lại bộ Salt Keys khi website không có sự cố.

Các thao tác khởi tạo ở Bước 1, Bước 2 và Bước 3 dưới đây chỉ dành riêng cho một website mới tinh chưa từng có file cấu hình, hoặc một bản sao (clone) dựng độc lập từ đầu để luyện tập. Với một website đang vận hành bình thường, bất kỳ thao tác đổi mật khẩu DB hay xoay vòng khóa Salt nào cũng là một ca bảo trì thực thụ — đòi hỏi phải sao lưu file cấu hình ra ngoài web root và chuẩn bị sẵn phương án hoàn nguyên trước khi đụng tay vào.

Chuẩn bị thông số riêng cho đúng website

Để bắt đầu với một site mới, bạn cần có bộ mã nguồn WordPress đã giải nén sẵn tại /var/www/lab-cf02, cặp database và tài khoản MariaDB riêng biệt đã chuẩn bị ở bài 37 hoặc bài 38, cùng tài khoản Linux dùng để triển khai (deploy user) đang nắm quyền sở hữu thư mục đó. Hãy mở trình quản lý mật khẩu (Password Manager) để lấy đúng tên DB, tên user, host (localhost) và chuỗi mật khẩu. Xin nhắc lại quy tắc bất di bất dịch: không bao giờ lấy tài khoản root của MariaDB làm tài khoản chạy WordPress.

Trên một VPS chạy nhiều website, tai nạn kinh điển nhất của anh em quản trị viên là mắt nhắm mắt mở sửa nhầm file wp-config.php của site A trong khi đang muốn chỉnh site B. Hãy đối chiếu thật kỹ đường dẫn root trong cấu hình NGINX với thư mục hiện tại bằng lệnh pwd và ls -l; đồng thời tập bỏ ngay thói quen gõ cat wp-config.php để xem nội dung, vì toàn bộ mật khẩu sẽ lập tức trôi tuột vào bộ đệm màn hình terminal và lưu lại trong nhật ký phiên làm việc!

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm tóm tắt 4 nhóm dữ liệu nhạy cảm cần bảo vệ quanh wp-config.php, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 1: khởi tạo file cấu hình với quyền 640 — chỉ áp dụng cho site mới

Hãy đăng nhập bằng tài khoản triển khai đang sở hữu thư mục website. Khối lệnh dưới đây được thiết kế riêng cho việc tạo mới lần đầu tiên, tuyệt đối không chạy bằng tài khoản root:

(
  set -euC
  cd /var/www/lab-cf02
  if [ -e wp-config.php ] || [ -L wp-config.php ]; then
    printf '%s\n' 'Dừng: wp-config.php đã tồn tại hoặc là symlink.' >&2
    exit 1
  fi
  test -r wp-config-sample.php
  umask 077
  cat wp-config-sample.php > wp-config.php
  sudo chgrp www-data wp-config.php
  chmod 640 wp-config.php
  php -l wp-config.php
)

Tại sao chúng ta không gõ đại một lệnh cp wp-config-sample.php wp-config.php cho nhanh mà lại viết một khối lệnh nhìn kỹ tính đến thế? Hãy cùng mổ xẻ từng lớp giáp bảo vệ bên trong:

• Cặp dấu ngoặc đơn ( ... ) gom toàn bộ thao tác vào một tiến trình shell con (subshell). Nếu có bất kỳ lỗi nào xảy ra, lệnh exit chỉ dừng khối lệnh đó chứ không làm văng mất cửa sổ SSH của bạn.
• Hai điều kiện -e và -L kiểm tra xem tên file wp-config.php đã tồn tại chưa — bao gồm cả trường hợp nó là một liên kết mềm bị đứt (broken symlink) trỏ tới một đích chưa tồn tại. Kết hợp thêm cờ set -C (noclobber), shell sẽ chặn đứng mọi hành vi vô tình ghi đè lên file cũ qua toán tử chuyển hướng >.
• Lệnh umask 077 được bật ngay trước khi đổ nội dung từ file mẫu sang file mới, đảm bảo ngay từ khoảnh khắc đầu tiên sinh ra trên ổ đĩa, file wp-config.php đã mang quyền 600 (chỉ chủ sở hữu đọc/ghi), không cho phép người lạ đọc trộm dù chỉ trong một phần nghìn giây trước khi kịp chạy lệnh chmod!
• Cuối cùng, nhóm sở hữu của file được chuyển sang www-data và chế độ quyền được mở vừa đủ ở mức 640 (chủ sở hữu đọc/ghi, nhóm www-data của PHP-FPM chỉ được đọc, còn mọi người dùng khác trên hệ thống bị chặn hoàn toàn với số 0 tròn trĩnh ở cuối).

Sau khi file mới đã được tạo ra và lệnh stat xác nhận đúng chủ sở hữu, nhóm và quyền 640, bạn mới mở trình soạn thảo văn bản bằng đường dẫn tuyệt đối (ví dụ: nano /var/www/lab-cf02/wp-config.php) để điền thông số. Tuyệt đối tránh trò dùng lệnh sed -i kèm mật khẩu trực tiếp trên dòng lệnh, vì cả chuỗi mật khẩu của bạn sẽ nằm chình ình trong file lịch sử ~/.bash_history.

Bước 2: điền bốn thông số kết nối cơ sở dữ liệu — chỉ cho file mới

Khi mở file wp-config.php vừa tạo trong trình soạn thảo, hãy tìm tới cụm bốn dòng định nghĩa hằng số kết nối DB gồm DB_NAME, DB_USER, DB_PASSWORD và DB_HOST để thay thế bằng thông tin thật của website:

define( 'DB_NAME', 'TEN_DB_TU_CAU_HINH_RIENG' );
define( 'DB_USER', 'USER_DB_TU_CAU_HINH_RIENG' );
define( 'DB_PASSWORD', 'BI_MAT_TU_KHO_LUU_RIENG' );
define( 'DB_HOST', 'localhost' );

Nhớ rằng các cụm chữ in hoa như TEN_DB_TU_CAU_HINH_RIENG hay BI_MAT_TU_KHO_LUU_RIENG ở trên chỉ là nhãn minh họa, bạn phải điền giá trị thực từ Password Manager của mình vào giữa cặp dấu nháy đơn. Hãy giữ nguyên cấu trúc cú pháp của PHP: tên hằng số và giá trị đều nằm trong dấu nháy đơn, kết thúc câu lệnh bằng dấu chấm phẩy ;. Nếu mật khẩu của bạn có chứa dấu nháy đơn ' hoặc dấu gạch chéo ngược \, hãy nhớ escape đúng quy tắc chuỗi của PHP kẻo gây lỗi cú pháp (syntax error).

Đối với hai dòng DB_CHARSET và DB_COLLATE ngay bên dưới, hãy giữ nguyên theo mặc định của file mẫu (thường là utf8 hoặc utf8mb4 và để trống DB_COLLATE). Bạn không cần hoang mang nếu thấy trong file mẫu ghi utf8 trong khi lúc tạo DB ở bài trước chúng ta dùng utf8mb4 — bộ lõi WordPress có cơ chế tự động thương lượng bảng mã kết nối chuẩn xác với MariaDB.

Bước 3: thay bộ khóa xác thực (Salt Keys) mới tinh — chỉ cho file mới

Kéo xuống thêm vài dòng, bạn sẽ bắt gặp 8 hằng số bảo mật bắt đầu bằng AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY cùng 4 hằng số _SALT tương ứng. Đây chính là “gia vị mật mã” mà WordPress dùng để băm (hash) và ký điện tử lên cookie đăng nhập cũng như các mã xác thực biểu mẫu (CSRF nonce). Nếu bạn lười biếng để nguyên dòng chữ mặc định put your unique phrase here hoặc chép đại một bộ khóa từ bài viết hướng dẫn trên mạng về dùng, kẻ tấn công có thể dễ dàng giả mạo cookie phiên đăng nhập của bạn!

Hãy truy cập trực tiếp vào dịch vụ tạo khóa chính thức của WordPress qua kết nối HTTPS an toàn tại địa chỉ https://api.wordpress.org/secret-key/1.1/salt/, sao chép toàn bộ 8 dòng kết quả ngẫu nhiên vừa sinh ra và dán đè vào đúng vị trí 8 dòng mẫu trong file wp-config.php của bạn. Mỗi website bắt buộc phải có một bộ Salt Keys riêng biệt, không dùng chung giữa các site và không bao giờ chụp ảnh vùng chứa khóa này đưa vào tài liệu báo cáo.

Một lưu ý vận hành quan trọng: nếu bạn thay đổi bộ Salt Keys trên một website đang hoạt động, toàn bộ người dùng và quản trị viên đang đăng nhập sẽ lập tức bị đăng xuất (vì cookie cũ không còn khớp chữ ký nữa). Tính năng này cực kỳ hữu ích khi bạn nghi ngờ tài khoản quản trị bị đánh cắp phiên đăng nhập (session hijacking) và muốn đá văng mọi phiên kết nối hiện tại ra khỏi hệ thống, nhưng trong ngày thường thì đừng tự ý xoay khóa nếu không có lý do.

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 khởi tạo và bảo vệ file cấu hình, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 4: khóa trình sửa code trực tiếp trong Dashboard

Mặc định, WordPress tích hợp sẵn một trình soạn thảo mã nguồn (Theme/Plugin File Editor) ngay trong giao diện quản trị, cho phép bất kỳ ai nắm tài khoản Admin cũng có thể mở file PHP của giao diện hoặc plugin ra gõ thêm code trực tiếp trên trình duyệt. Trong thực tế vận hành, đây là món quà trời cho đối với hacker: nếu chúng chiếm được một tài khoản quản trị viên, chúng chỉ việc mở Theme Editor lên chèn vài dòng mã độc là làm chủ hoàn toàn máy chủ. Để bịt cánh cửa nguy hiểm này lại, hãy thêm dòng cấu hình sau vào phía trên dòng chú thích /* That's all, stop editing! ... */:

define( 'DISALLOW_FILE_EDIT', true );

Tất nhiên, bạn cần hiểu đúng bản chất kỹ thuật: hằng số DISALLOW_FILE_EDIT chỉ ẩn và vô hiệu hóa trình sửa code trên giao diện Dashboard chứ không ngăn cản việc cài đặt plugin mới hay thay thế cho việc phân quyền file trên hệ điều hành Linux (đó là lý do ở bài 40 chúng ta vẫn phải khóa quyền ghi của PHP đối với thư mục mã nguồn). Cũng đừng nhầm nó với hằng số mạnh tay hơn là DISALLOW_FILE_MODS — vốn sẽ khóa luôn cả chức năng cài đặt và cập nhật plugin/theme qua giao diện web.

Về chế độ gỡ lỗi (debug): trên môi trường chạy thật (production), hãy luôn giữ WP_DEBUG ở giá trị false. Nếu cần bật WP_DEBUG_LOG trong chốc lát trên môi trường thử nghiệm để bắt bệnh, hãy nhớ điều hướng file log ra ngoài thư mục web công khai (hoặc chặn tải xuống bằng NGINX) và tắt ngay khi sửa xong lỗi, bởi các bản ghi stack trace khi lỗi rất hay vô tình in kèm cả tham số đầu vào nhạy cảm.

Bước 5: xác minh cú pháp và quyền truy cập mà không làm lộ mật khẩu

Làm sao để biết file wp-config.php vừa chỉnh sửa đã chuẩn chỉ mà không cần in nội dung của nó ra màn hình? Hãy chạy bộ ba câu lệnh kiểm tra tinh gọn dưới đây:

php -l /var/www/lab-cf02/wp-config.php
stat -c '%U %G %a %n' /var/www/lab-cf02/wp-config.php
sudo -u www-data test -r /var/www/lab-cf02/wp-config.php

Hãy xem bộ ba này phối hợp với nhau mượt mà thế nào: (1) Lệnh php -l (lint) chỉ rà soát cú pháp ngôn ngữ PHP và báo No syntax errors detected chứ không thực thi hay in ra biến mật khẩu; (2) lệnh stat xác nhận chủ sở hữu là user triển khai, nhóm là www-data và chế độ quyền đúng chuẩn 640; (3) lệnh sudo -u www-data test -r ... đóng vai tiến trình PHP-FPM để kiểm tra xem ứng dụng có thực sự đọc được file cấu hình hay không (lệnh test chạy êm ru không in gì ra màn hình, mã thoát bằng 0 nghĩa là đọc thành công).

Chưa hết, hãy nhớ lại một thói quen cực kỳ tai hại của nhiều anh em khi sửa file: tạo các bản sao lưu dự phòng kiểu wp-config.php.bak, wp-config.php.old, wp-config.php.save hoặc wp-config.txt ngay bên trong thư mục gốc của website! Tại sao nó lại nguy hiểm chết người? Bởi vì đối với NGINX, một file có đuôi .bak hay .txt không còn là file .php nữa — nếu không có quy tắc chặn trong NGINX, bất kỳ ai gõ đường dẫn https://ten-mien-cua-ban/wp-config.php.bak trên trình duyệt cũng sẽ tải được nguyên văn toàn bộ mật khẩu database về máy dưới dạng văn bản thuần! Vì vậy, nguyên tắc sắt đá là: mọi bản sao lưu của file cấu hình phải được cất ở thư mục riêng nằm ngoài web root với quyền 600, và cấu hình NGINX phải chặn truy cập trực tiếp vào cả tên file chính lẫn các đuôi file sao lưu phổ biến.

Cách xử lý sự cố cú pháp và quy trình hoàn nguyên (Rollback)

Nếu lệnh php -l báo lỗi cú pháp (Parse error) tại một dòng cụ thể, bạn chỉ cần mở trình soạn thảo nhảy tới đúng dòng đó (và dòng ngay phía trên nó) để kiểm tra xem có thiếu dấu nháy đơn ', dấu phẩy ,, dấu đóng ngoặc ) hay dấu chấm phẩy ; nào không. Tuyệt đối đừng copy nguyên dòng code đang chứa mật khẩu thật đem dán lên các diễn đàn hay nhóm chat để hỏi lỗi nhé!

Trước mỗi lần chỉnh sửa file wp-config.php của website đang vận hành, hãy luôn sao lưu một bản ra thư mục riêng ngoài web root (mode 700 cho thư mục và 600 cho file). Nhờ vậy, nếu sửa xong mà thấy trang web gặp trục trặc, bạn có thể hoàn nguyên lại bản sao lưu chỉ trong vài giây. Chỉ cần lưu ý một điều: nếu trong ca bảo trì đó bạn vừa đổi cả mật khẩu trong MariaDB bằng lệnh ALTER USER, thì việc chép đè lại file wp-config.php cũ chứa mật khẩu cũ sẽ làm đứt kết nối database ngay — khi hoàn nguyên phải đồng bộ cả file cấu hình lẫn mật khẩu trong DB.

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

Câu hỏi thường gặp

Đưa mật khẩu DB vào biến môi trường (environment variables) thay vì ghi trong file có phải lúc nào cũng tốt hơn không? Chỉ tốt hơn khi hạ tầng của bạn đã có quy trình quản lý, cấp phát và bảo vệ biến môi trường chặt chẽ cho từng pool PHP-FPM. Nhiều bạn đọc blog thấy người ta khuyên dùng getenv() liền làm theo mà quên mất tiến trình worker của PHP-FPM mặc định có thể xóa sạch môi trường (clear_env = yes) hoặc làm lộ biến qua trang phpinfo()! Với kiến trúc LEMP tiêu chuẩn trên VPS, đặt cấu hình trong file wp-config.php được khóa quyền 640 là phương án rõ ràng, dễ kiểm soát và an toàn bậc nhất.

Có được phép đưa file wp-config-sample.php vào kho chứa Git không? Hoàn toàn được, miễn là file mẫu đó chỉ chứa các nhãn giữ chỗ mặc định và không dính bất kỳ thông tin mật khẩu hay khóa thật nào. Còn file wp-config.php thật đang chạy thì bắt buộc phải nằm trong danh sách loại trừ .gitignore.

Đổi tiền tố bảng ($table_prefix) từ wp_ sang chuỗi khác có giúp website miễn nhiễm với hacker không? Không hề. Việc đặt một tiền tố riêng lúc cài mới chỉ là một lớp làm khó những kịch bản tấn công tự động sơ sài, chứ nếu một plugin bị lỗi SQL Injection thực sự thì kẻ tấn công vẫn có thể truy vấn tên bảng từ information_schema. Đặc biệt, với website đang chạy có sẵn dữ liệu, bạn tuyệt đối không được tự ý sửa biến $table_prefix trong wp-config.php, vì làm vậy WordPress sẽ tưởng cơ sở dữ liệu chưa có bảng nào và ngừng hiển thị toàn bộ bài viết cũ.

Biên bản nghiệm thu trên LAB-CF-02 ngày 30/09/2026

Đợt rà soát thực tế vào lúc 23:01 ngày 30/09/2026 (UTC+7) trên file wp-config.php đang vận hành của máy chủ LAB-CF-02 ghi nhận các thông số sau:

Nhờ kỹ thuật chỉ trích xuất kết quả kiểm tra dưới dạng giá trị logic (true/false) và mã thoát, biên bản nghiệm thu chứng minh được bộ cấu hình tuân thủ đúng tiêu chuẩn mà không cần lưu lại dù chỉ một ký tự của mật khẩu DB hay khóa Salt. Tất nhiên, phép kiểm tra độ dài và tính độc nhất của 8 chuỗi Salt chỉ giúp phát hiện lỗi quên thay khóa mẫu chứ không tự đánh giá độ ngẫu nhiên mật mã học (entropy) của nguồn sinh khóa.

Thực nghiệm chốt chặn (Guard) tạo file an toàn ngày 01/10/2026

Để chứng minh khối lệnh subshell ở Bước 1 thực sự bảo vệ người dùng trước mọi tình huống rủi ro, vào lúc 04:35:24 ngày 01/10/2026 (giờ Việt Nam) trên máy chủ LAB-CF-02, chúng tôi đã dựng các thư mục nháp biệt lập chứa bản sao wp-config-sample.php và chạy thử nghiệm 5 kịch bản biên (edge cases) mà không hề chạm vào file cấu hình thật của website đang chạy:

Trên file cấu hình mới được tạo ra ở kịch bản đầu tiên, chúng tôi cũng đóng vai user www-data để kiểm tra: phép thử quyền đọc (test -r) trả về mã thoát 0 (đọc được), trong khi phép thử quyền ghi (test -w) trả về mã thoát 1 (bị từ chối ghi). Như vậy, tiến trình PHP-FPM chỉ có thể đọc cấu hình chứ không thể tự sửa đổi file này. Toàn bộ thư mục nháp đã được dọn dẹp sạch sẽ ngay sau khi hoàn tất bài test.

Ảnh chụp console xác minh quyền file hiện hành lúc 10:52

Vào lúc 10:52:49 ngày 01/10/2026 (UTC+7), chúng tôi thực hiện đợt xác minh trực tiếp trên file wp-config.php của website gốc trên LAB-CF-02 và ghi nhận: cú pháp PHP hợp lệ, chủ sở hữu và nhóm là tutorial:www-data với chế độ quyền 640, tiến trình PHP-FPM (www-data) đọc được file cấu hình nhưng không có quyền ghi vào file mã nguồn index.php (mode 644). Tiến trình pool FPM lắng nghe tại /run/php/php8.3-fpm.sock với owner/group khớp chuẩn www-data.

Ảnh chụp màn hình console thực tế lúc 10:53:28 ngày 01/10/2026 (UTC+7) của đợt chạy bắt đầu lúc 10:52:49; giữ nguyên điểm ảnh gốc và đính kèm logo nhận diện. Ảnh hiển thị kết quả thực thi lệnh mà không làm lộ bất kỳ mật khẩu hay chuỗi khóa Salt nào. Bấm vào ảnh để mở kích thước đầy đủ.

Các yêu cầu HTTP HEAD gửi tới /wp-config.php, /wp-config.php.bak và /wp-config.php.old lần lượt nhận mã phản hồi 403, 403 và 404, xác nhận máy chủ web không cho phép tải xuống các đường dẫn này.

Thực nghiệm thay đổi một hằng số rồi hoàn nguyên trên site clone lúc 10:57

Để minh họa quy trình sửa cấu hình an toàn (sao lưu → kiểm tra cú pháp bản nháp → áp dụng nguyên tử → hoàn nguyên), trong khoảng thời gian từ 10:57:29 đến 10:57:32 ngày 01/10/2026 (UTC+7), chúng tôi thực hiện bài test trên website bản sao restore-cf02.test:8081. Trước khi chỉnh sửa, trong file cấu hình chưa khai báo hằng số WP_POST_REVISIONS (nên khi WordPress khởi chạy, bộ lõi tự động gán giá trị mặc định trong runtime là true). Kịch bản đã dùng lệnh wp config has để phân biệt rõ giữa việc hằng số được khai báo tường minh trong file với giá trị mặc định trong bộ nhớ.

Ảnh chụp màn hình console thực tế lúc 10:58:11 ngày 01/10/2026 (UTC+7), giữ nguyên điểm ảnh gốc và đính kèm logo ở chân ảnh. Kịch bản phát kết quả tại mốc 03:57:29–32 UTC (tương ứng 10:57:29–32 giờ Việt Nam). Bấm vào ảnh để xem kích thước đầy đủ.

Bài thực nghiệm trên cho thấy lợi ích to lớn của thói quen kiểm tra cú pháp trên file nháp (staging file) trước khi đưa vào vị trí chạy thật: ngay cả khi bạn gõ thiếu một dấu chấm phẩy, lệnh php -l sẽ tuýt còi ngay lập tức thay vì để trang web của khách biến thành màn hình trắng (lỗi HTTP 500)!

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

Tài liệu chính thức từ WordPress: wp-config.php đã được đối chiếu lại vào ngày 01/10/2026. Hai tài liệu nền tảng là WordPress: gia cố bảo mật (Hardening) và WordPress: phân quyền file được đối chiếu ngày 30/09/2026.

Ngoài ra, chúng tôi đối chiếu bổ sung vào ngày 01/10/2026 hai tài liệu kỹ thuật: WP-CLI config set (về cách gán giá trị hằng số kiểu số nguyên/boolean) và WordPress: wp_functionality_constants (quy định giá trị mặc định true của WP_POST_REVISIONS khi chưa khai báo trong file cấu hình).

Nếu website của bạn đã có sẵn file cấu hình, hãy chạy ngay bộ lệnh xác minh ở Bước 5 rồi chuyển sang bài tiếp theo: Quyền file WordPress: tìm nguyên nhân lỗi ghi file. Xem toàn bộ thứ tự các bài học trong lộ trình WordPress trên VPS.