Danh mục: Quản trị web

Bạn đã bấm đúng nút, bản ghi đã hiện trong bảng quản lý, mà mở tên miền lên vẫn ra trang cũ hoặc lỗi “không tìm thấy máy chủ”. Chín trên mười trường hợp như vậy không phải do landing page hỏng, mà do một trong bốn thứ ở tầng DNS: sai nameserver, sai loại bản ghi, còn bản ghi cũ chồng lên, hoặc đơn giản là chưa hết thời gian lưu đệm.

Bài này giải thích cơ chế bên dưới để bạn tự chẩn đoán được, thay vì thử ngẫu nhiên rồi chờ. Phần thao tác cụ thể trong dashboard ivi.vn nằm ở Bài 4 của loạt hướng dẫn sử dụng; ở đây ta nói về phần bên dưới cái nút đó.

Chuyện gì xảy ra trước khi trang hiện ra

Khi ai đó gõ tên miền của bạn, trình duyệt không biết máy chủ nào giữ nội dung. Nó hỏi một máy chủ phân giải, thường là của nhà mạng, và máy chủ đó đi hỏi lần lượt:

1. Hỏi nhóm máy chủ gốc: ai quản đuôi .com (hoặc .vn)?
2. Hỏi máy chủ của đuôi đó: tên miền này giao cho nameserver nào?
3. Hỏi chính nameserver đó: bản ghi cho tên này là gì?

Chỉ câu trả lời ở bước ba mới là thứ bạn sửa được trong bảng quản lý DNS. Và nó chỉ được hỏi tới nếu bước hai chỉ đúng về máy chủ bạn đang sửa. Đây là nguồn gốc của lỗi phổ biến nhất.

Nameserver quyết định ai được phép trả lời

Một tên miền có thể có bản ghi ở nhiều nơi cùng lúc: ở nhà đăng ký, ở một nhà cung cấp DNS cũ, ở hệ thống của ivi.vn. Nhưng chỉ nơi được nameserver chỉ đến mới thật sự phát ra câu trả lời. Mọi bản ghi bạn sửa ở những nơi còn lại đều nằm im, không ai hỏi tới.

Vì vậy màn quản lý tên miền của ivi.vn có một cảnh báo riêng: khi phát hiện nameserver đang trỏ về nơi khác, nó nói thẳng rằng bản ghi sửa ở đây chưa có tác dụng trên Internet, và mời bạn sang tab tên miền để chuyển nameserver về hệ thống DNS của ivi.vn. Đọc được cảnh báo đó là tiết kiệm được một buổi chiều.

Kiểm tra nameserver hiện hành bằng một lệnh:

dig NS tenmien.com +short
nslookup -type=NS tenmien.com

Kết quả trả về là danh sách nameserver đang có thẩm quyền. Nếu nó không phải bộ bạn nghĩ, dừng lại và xử lý bước này trước, đừng sửa bản ghi thêm nữa.

A hay CNAME: chọn đúng loại bản ghi

Hai loại bản ghi bạn dùng đến 95% thời gian:

	Bản ghi A	Bản ghi CNAME
Giá trị chứa gì	Một địa chỉ IPv4, ví dụ 203.0.113.10	Một tên miền khác, ví dụ dns.nhacungcap.io
Dùng khi	Bạn biết chắc địa chỉ IP của máy chủ và nó ổn định	Bên kia bảo bạn trỏ về tên miền của họ
Khi bên kia đổi máy chủ	Bạn phải tự vào sửa lại IP	Bạn không phải làm gì, họ sửa bên họ
Đặt ở gốc @ được không	Được	Theo chuẩn thì không, trừ khi nhà cung cấp DNS hỗ trợ cơ chế thay thế

Dòng cuối là chỗ hay gây bực. Theo quy định của DNS, một tên đã có bản ghi CNAME thì không được có bất kỳ bản ghi loại nào khác tại cùng tên đó. Trong khi gốc của tên miền bắt buộc luôn tồn tại bản ghi SOA và NS. Hai điều đó mâu thuẫn, nên CNAME ở gốc là sai chuẩn.

Hậu quả thực tế nếu bạn cố ép: bản ghi MX ở gốc cũng bị vô hiệu, tức là email theo tên miền của bạn ngừng nhận thư. Đây là kiểu hỏng âm thầm — website chạy ngon, còn thư khách gửi tới thì bật lại người gửi mà bạn không biết.

Cách xử lý phổ biến:

• Dùng một tên miền con cho landing page, ví dụ lp.tenmien.com hoặc www.tenmien.com, rồi đặt CNAME ở đó. Gốc để chuyển hướng sang tên miền con.
• Hoặc dùng nhà cung cấp DNS có hỗ trợ bản ghi kiểu ALIAS: bên ngoài trông như CNAME, nhưng máy chủ tự phân giải sẵn rồi trả về địa chỉ IP, nên không vi phạm quy tắc trên. Trong màn Landing Page của ivi.vn, phần này hệ thống tự lo khi bạn bấm kích hoạt; còn khi tự khai báo ở nơi khác thì phải kiểm tra trước.

Vùng DNS trên ivi.vn nhận sáu loại bản ghi: A, AAAA, CNAME, MX, TXT, CAA. AAAA là bản IPv6 của A. TXT giữ các chuỗi xác thực như SPF hay DKIM cho email. CAA khai báo tổ chức nào được phép cấp chứng chỉ bảo mật cho tên miền của bạn.

TTL: vì sao đổi xong không thấy ngay

Mỗi bản ghi đi kèm một con số TTL tính bằng giây. Nó là lời cho phép: máy chủ phân giải nào nhận được câu trả lời này thì được giữ lại và dùng lại trong chừng ấy giây, không cần hỏi lại.

Điểm hầu hết mọi người hiểu ngược: khi bạn sửa một bản ghi, thứ quyết định bạn phải chờ bao lâu là TTL của bản ghi cũ, không phải TTL của bản ghi mới. Các máy chủ đã lưu bản cũ vẫn trả bản cũ cho tới khi hết hạn lưu đệm của chính nó. Đặt TTL mới xuống 300 giây không rút ngắn được lần chờ này — nó chỉ giúp cho lần đổi sau.

Vì vậy quy trình chuyên nghiệp là: biết trước sẽ đổi thì hạ TTL xuống mức thấp một hai ngày trước, đổi bản ghi, kiểm tra xong rồi nâng TTL trở lại. Trên ivi.vn, ô thời gian lưu đệm nhận giá trị trong khoảng 300 đến 86400 giây; đặt ngoài khoảng đó thì hệ thống tự kẹp về biên, nên số bạn nhìn thấy có thể lệch số thật sự được lưu.

Có một dạng lưu đệm nữa ít người biết: lưu đệm câu trả lời phủ định. Nếu bạn mở thử tên miền trước khi tạo bản ghi, máy chủ phân giải nhận được câu trả lời “không tồn tại” và nó cũng lưu câu trả lời đó lại một khoảng thời gian. Đó là lý do việc nôn nóng kiểm tra sớm lại làm bạn phải chờ lâu hơn. Tạo bản ghi trước, kiểm tra sau.

Kiểm tra bằng công cụ tra cứu

Đừng dùng trình duyệt làm công cụ chẩn đoán: trình duyệt và hệ điều hành đều giữ bộ nhớ đệm riêng nên không phản ánh trạng thái DNS thật. Hỏi thẳng bằng lệnh:

dig +short lp.tenmien.com CNAME
dig +short lp.tenmien.com A
dig NS tenmien.com +short
dig @8.8.8.8 lp.tenmien.com

Trên Windows không có dig sẵn thì dùng:

nslookup -type=CNAME lp.tenmien.com
nslookup -type=A lp.tenmien.com
ipconfig /flushdns

Cách đọc kết quả:

• Trả về đúng giá trị bạn vừa đặt: tầng DNS xong việc. Nếu trang vẫn lỗi thì vấn đề nằm ở phía máy chủ đích, không phải ở đây.
• Trả về giá trị cũ: còn trong thời gian lưu đệm. Chờ hết TTL cũ.
• Không trả về gì: bản ghi chưa tồn tại ở nameserver có thẩm quyền, hoặc bạn đang sửa ở sai nơi. Quay lại kiểm tra nameserver.
• Hỏi thẳng một máy chủ phân giải công cộng ra kết quả đúng, còn máy bạn ra kết quả cũ: bản ghi đã lan rồi, chỉ máy hoặc nhà mạng của bạn còn giữ bản cũ. Xoá đệm máy rồi thử lại.

Ngoài dòng lệnh còn có các trang tra cứu DNS nhiều điểm, hỏi cùng lúc từ nhiều quốc gia. Chúng hữu ích để trả lời câu hỏi “chỉ mình tôi thấy sai hay cả thế giới đều sai”.

Bảng lỗi hay gặp

Hiện tượng	Nguyên nhân	Cách sửa
Sửa bản ghi mãi không ăn	Nameserver đang trỏ về nơi khác	Chuyển nameserver về nơi bạn đang sửa, rồi chờ hết TTL
Ra trang cũ dù đã đổi	Bản ghi A cũ vẫn còn, nằm song song với bản ghi mới	Xoá bản ghi cũ; một tên chỉ nên có một đích
Gốc chạy, thêm www thì lỗi	Chỉ tạo bản ghi ở gốc, quên tên miền con www	Tạo thêm bản ghi cho www, thường là CNAME trỏ về gốc
Web chạy nhưng email chết	Đặt CNAME ở gốc làm vô hiệu bản ghi MX	Chuyển landing page sang tên miền con, trả gốc về bản ghi A
Trình duyệt báo kết nối không an toàn	Chứng chỉ chưa cấp xong; bên cấp phải xác thực quyền kiểm soát qua HTTP hoặc qua bản ghi DNS, nên phải trỏ đúng trước đã	Chờ chứng chỉ được cấp, đừng đổi lại DNS giữa chừng. Chi tiết ở bài về chứng chỉ SSL
Đổi cả buổi vẫn chưa lan	TTL cũ đặt ở mức một ngày	Chờ hết chu kỳ; lần sau hạ TTL trước khi đổi
Máy này vào được, máy kia không	Hai máy dùng máy chủ phân giải khác nhau, lan chưa đều	Bình thường, chờ thêm; kiểm tra bằng công cụ tra cứu nhiều điểm

Ba thói quen tránh được phần lớn rắc rối

• Ghi lại cấu hình trước khi sửa. Chụp màn hình bảng bản ghi hiện tại. Khi có sự cố, biết trạng thái cũ giúp quay lui trong hai phút thay vì dựng lại từ trí nhớ.
• Đổi một thứ mỗi lần. Đổi nameserver, đổi bản ghi gốc và đổi bản ghi www cùng lúc thì khi hỏng bạn không biết cái nào gây ra.
• Đừng đụng vào bản ghi MX và TXT khi chỉ định trỏ web. Chúng phục vụ email. Xoá nhầm một bản ghi TXT xác thực người gửi là thư của bạn bắt đầu rơi vào hộp thư rác, mà triệu chứng lộ ra rất muộn.

Tóm lại

Trỏ tên miền về landing page thực chất là bốn câu hỏi theo thứ tự: nameserver có đúng chỗ không, loại bản ghi có đúng không, còn bản ghi cũ nào chồng lên không, và TTL cũ đã hết chưa. Trả lời được bốn câu đó bằng công cụ tra cứu là bạn không còn phải đoán. Riêng chuyện CNAME ở gốc thì nhớ một điều: nó có thể lấy đi email của bạn mà không báo trước.

Nếu bạn muốn phần thao tác cụ thể trên dashboard thay vì phần lý thuyết, xem hướng dẫn trỏ tên miền về Landing Page trong dashboard. Còn nếu bạn đang cần một tên miền để bắt đầu, tra thử tại ivi.vn/search.

Website đang chạy quảng cáo bỗng phản hồi chậm rồi ngừng hẳn, trong khi bảng thống kê hiển thị lượng truy cập tăng vọt. Đó là lúc bạn phải trả lời một câu hỏi trong vài phút: đây là khách thật đông bất thường, là bot cào dữ liệu, hay là một đợt tấn công từ chối dịch vụ.

Bài này viết ở tầng phòng thủ cho người quản trị website vừa và nhỏ: cách nhận biết, các lớp bảo vệ nên dựng sẵn, và trình tự thao tác khi sự cố đang diễn ra. Không có phần nào nói về cách tấn công, vì đó là việc trái pháp luật và cũng không giúp bạn phòng thủ tốt hơn.

Hiểu đúng vấn đề trước khi mua giải pháp

Tấn công từ chối dịch vụ phân tán nhắm tới việc làm cạn một loại tài nguyên nào đó. Với người quản trị, chỉ cần phân biệt hai nhóm:

• Nhóm gây ngập băng thông và kết nối: lưu lượng rác đổ vào đường truyền hoặc mở thật nhiều kết nối dở dang. Máy chủ chưa kịp xử lý gì thì đường đã tắc. Loại này gần như không thể chống bằng cấu hình phần mềm trên chính máy chủ đó — phải có một lớp lọc đứng trước.
• Nhóm nhắm vào ứng dụng: gửi các yêu cầu trông như người thật nhưng chọn đúng những trang tốn tài nguyên nhất — trang tìm kiếm nội bộ, trang lọc sản phẩm nhiều tham số, trang đăng nhập. Số yêu cầu không cần nhiều, chỉ cần đủ để lấp hết tiến trình xử lý. Đây là loại mà website nhỏ hay gặp nhất, và cũng là loại bạn tự làm được nhiều nhất.

Cần phân biệt với hai hiện tượng dễ nhầm: một là bot thu thập dữ liệu chạy quá nhanh (chỉ cần điều tiết, không phải kẻ tấn công); hai là chính website của bạn thiếu bộ nhớ đệm nên chỉ vài trăm người truy cập cùng lúc đã đủ sập. Trường hợp thứ hai không cần chống tấn công, cần tối ưu.

Nhận biết: đọc dấu hiệu thay vì đoán

Dấu hiệu quan sát được	Nghiêng về khả năng
Lưu lượng tăng, đơn hàng và thời gian ở lại trang cũng tăng theo	Khách thật, cần tăng năng lực phục vụ
Lưu lượng tăng gấp nhiều lần nhưng chuyển đổi bằng không	Bot hoặc tấn công
Yêu cầu dồn vào một đường dẫn duy nhất, nhiều tham số lạ	Tấn công tầng ứng dụng
Cùng một chuỗi nhận dạng trình duyệt lặp lại hàng loạt	Công cụ tự động
Rất nhiều kết nối ở trạng thái nửa mở	Tấn công tầng kết nối
Tiến trình xử lý mã nguồn chiếm hết, cơ sở dữ liệu chờ khoá	Đang bị bào bằng truy vấn nặng
Băng thông chạm trần trong khi số yêu cầu không tăng tương ứng	Có tệp lớn đang bị tải lặp, hoặc ngập băng thông

Vài lệnh đọc tình hình nhanh trên máy chủ Linux:

# Đếm số kết nối theo trạng thái
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn
# Các đường dẫn bị gọi nhiều nhất trong nhật ký truy cập
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Phân bố theo địa chỉ nguồn
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Theo dõi tải và tiến trình theo thời gian thực
top -o %CPU

Ghi lại kết quả ngay lúc sự cố. Sau khi mọi thứ ổn định, nhật ký thường bị xoay vòng và bạn mất bằng chứng để rút kinh nghiệm.

Sáu lớp phòng thủ nên dựng sẵn

1. Đặt một lớp lọc đứng trước máy chủ

Đây là biện pháp có hiệu quả cao nhất và cũng dễ triển khai nhất. Một mạng phân phối nội dung hoặc dịch vụ lọc trung gian sẽ nhận lưu lượng thay bạn, hấp thụ phần rác ở tầng mạng và chỉ chuyển về máy chủ gốc phần yêu cầu hợp lệ. Với nhóm tấn công gây ngập băng thông, đây gần như là cách duy nhất khả thi cho website vừa và nhỏ.

Khi chọn, hãy nhìn vào ba năng lực cụ thể thay vì lời quảng cáo: có bật được chế độ kiểm tra trình duyệt cho toàn site không, có đặt được luật giới hạn tần suất theo đường dẫn không, và có cho xem nhật ký để bạn biết cái gì đã bị chặn không.

2. Không để lộ địa chỉ máy chủ gốc

Dựng lớp lọc phía trước mà địa chỉ máy chủ gốc vẫn công khai thì lưu lượng có thể đi vòng qua lớp lọc. Những chỗ hay làm lộ:

• Bản ghi DNS cũ còn sót lại của tên miền con không dùng nữa.
• Bản ghi phục vụ thư điện tử trỏ thẳng vào cùng máy chủ đặt website.
• Thư do ứng dụng gửi đi mang tiêu đề chứa địa chỉ máy chủ.
• Chứng chỉ bảo mật cấp cho tên miền nội bộ, tra được trong nhật ký minh bạch chứng chỉ công khai.

Việc cần làm kèm theo: cấu hình máy chủ web từ chối mọi yêu cầu không đi qua lớp lọc — hoặc bằng tường lửa chỉ chấp nhận dải địa chỉ của lớp lọc, hoặc bằng cách yêu cầu một tiêu đề bí mật. Không có bước này thì việc giấu địa chỉ chỉ là che mắt.

3. Bật bộ nhớ đệm toàn trang

Mỗi yêu cầu được trả từ bộ nhớ đệm là một yêu cầu không chạm tới mã nguồn và cơ sở dữ liệu. Khoảng cách giữa hai trường hợp thường là vài bậc độ lớn về tài nguyên tiêu tốn. Với website nội dung, bật bộ nhớ đệm toàn trang là biện pháp chống quá tải rẻ nhất mà lại có ích cả ngày thường.

Ba điểm cần chú ý: đặt thời gian sống của bản đệm đủ dài; loại trừ đúng các trang cần cá nhân hoá như giỏ hàng và tài khoản; và cẩn thận với việc đặt cookie trên mọi phản hồi, vì đó là lý do phổ biến khiến lớp đệm phía trước không bao giờ lưu được gì.

4. Tách tài nguyên tĩnh ra khỏi đường xử lý động

Ảnh, video, tệp CSS và JavaScript nên được phục vụ từ lớp phân phối nội dung với thời hạn lưu trữ dài, đặt tên tệp có gắn phiên bản để đổi nội dung thì đổi tên. Như vậy phần lớn số yêu cầu và phần lớn băng thông không bao giờ tới máy chủ gốc, và khi có sự cố thì máy chủ gốc chỉ còn phải lo phần động.

5. Giới hạn tần suất và giới hạn kết nối

Đây là tuyến phòng thủ tại chỗ, nên đặt ngay cả khi đã có lớp lọc phía trước. Nguyên tắc: mỗi nguồn chỉ được gọi một đường dẫn nhất định với tần suất hợp lý; vượt ngưỡng thì bị làm chậm rồi mới bị từ chối.

# Ví dụ cấu hình nginx: hai vùng đo, một cho toàn site, một cho trang đăng nhập
limit_req_zone  $binary_remote_addr zone=chung:10m   rate=10r/s;
limit_req_zone  $binary_remote_addr zone=dangnhap:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=ketnoi:10m;
server {
    # Cho phép bùng ngắn hạn, không trả lỗi ngay
    limit_req  zone=chung burst=20 nodelay;
    limit_conn ketnoi 20;
    client_body_timeout   10s;
    client_header_timeout 10s;
    send_timeout          10s;
    location = /wp-login.php {
        limit_req zone=dangnhap burst=5 nodelay;
    }
}

Đặt ngưỡng bằng cách đo lưu lượng ngày thường trước, rồi lấy mức đỉnh nhân lên vài lần. Ngưỡng quá chặt sẽ chặn nhầm khách thật và cả bot của công cụ tìm kiếm. Sau khi bật, hãy theo dõi nhật ký vài ngày để chỉnh lại.

6. Khoá bớt các điểm tốn tài nguyên

• Trang tìm kiếm nội bộ: yêu cầu độ dài từ khoá tối thiểu, đặt giới hạn tần suất riêng, và đệm kết quả cho các từ khoá phổ biến.
• Giao diện lập trình cũ không dùng tới: tắt hẳn thay vì để mở.
• Trang đăng nhập và trang quản trị: giới hạn theo địa chỉ nguồn nếu được, bật xác thực nhiều bước, đặt độ trễ tăng dần sau mỗi lần sai.
• Các đường dẫn sinh tệp nặng theo yêu cầu như xuất báo cáo hay tạo ảnh động: đưa vào hàng đợi xử lý nền và yêu cầu đăng nhập.
• Chức năng gửi thư từ biểu mẫu công khai: thêm bước xác thực người dùng và giới hạn số lần gửi.

Chuẩn bị trước để không phải xoay xở lúc đang cháy

1. Hạ TTL của các bản ghi DNS quan trọng xuống mức thấp và giữ như vậy. Khi cần chuyển hướng lưu lượng khẩn cấp, TTL cao sẽ trói bạn hàng giờ.
2. Giám sát từ bên ngoài với cảnh báo qua kênh bạn thật sự đọc. Biết sớm 10 phút là khác biệt lớn.
3. Viết sẵn sổ tay xử lý: ai làm gì, đăng nhập ở đâu, bật chế độ phòng thủ ở đâu, số liên hệ của nhà cung cấp hạ tầng.
4. Chuẩn bị sẵn trang tĩnh dự phòng chỉ gồm HTML và thông tin liên hệ, có thể bật lên khi cần chịu tải mà không cần cơ sở dữ liệu.
5. Kiểm tra bản sao lưu bằng cách khôi phục thử. Bản sao lưu chưa từng khôi phục không tính là bản sao lưu.
6. Biết trần chịu tải của mình: chạy một phép đo tải trên môi trường thử nghiệm của chính bạn để biết ngưỡng gãy nằm ở đâu.

Khi đang bị tấn công: thứ tự thao tác

1. Xác nhận đúng hiện tượng. Xem nhật ký và số kết nối, phân biệt quá tải do khách thật hay do lưu lượng rác. Xử lý sai hướng còn tệ hơn không xử lý.
2. Bật mức phòng thủ cao nhất ở lớp lọc phía trước, ví dụ chế độ kiểm tra trình duyệt cho toàn bộ website. Chấp nhận phiền phức cho khách trong vài giờ để giữ dịch vụ sống.
3. Thu hẹp mục tiêu. Nếu áp lực dồn vào một vài đường dẫn, tạm khoá hoặc trả về bản tĩnh cho đúng những đường dẫn đó thay vì chặn cả site.
4. Tăng tỷ lệ phục vụ từ bộ nhớ đệm, kể cả bằng cách kéo dài thời gian sống của bản đệm tạm thời.
5. Liên hệ nhà cung cấp hạ tầng. Họ nhìn được tầng mạng mà bạn không nhìn được và có thể chặn giúp ở phía trên.
6. Ghi lại toàn bộ. Thời điểm bắt đầu, đặc điểm lưu lượng, thao tác đã làm và tác dụng của từng thao tác.
7. Sau khi yên, gỡ dần các biện pháp khẩn cấp và giữ lại những gì đáng giữ. Đừng để chế độ kiểm tra gắt chạy mãi rồi quên.

Hai điều tuyệt đối không làm: không trả đũa dưới bất kỳ hình thức nào — đó là hành vi vi phạm pháp luật và không làm lưu lượng vào bạn giảm đi; và không đổi tên miền hay đổi máy chủ trong lúc hoảng loạn, vì bạn sẽ tự tạo thêm một sự cố mới chồng lên sự cố đang có.

Vệ sinh nền tảng: phần ít hào nhoáng nhưng cứu bạn nhiều nhất

• Cập nhật hệ quản trị nội dung và các trình cắm. Phần lớn website nhỏ “sập” không phải vì bị nhắm mục tiêu, mà vì bị quét lỗ hổng hàng loạt.
• Gỡ trình cắm và giao diện không dùng, thay vì chỉ tắt.
• Bật HTTPS trên toàn bộ website và bảo đảm gia hạn chứng chỉ tự động chạy đều — xem Hướng dẫn lấy chứng chỉ SSL Let’s Encrypt.
• Tách môi trường thử nghiệm khỏi môi trường chạy thật, và chặn truy cập công khai vào môi trường thử nghiệm.
• Giữ cấu hình DNS gọn: xoá bản ghi cũ, biết chính xác mỗi bản ghi đang trỏ về đâu. Nếu bạn vừa chuyển hosting, đối chiếu lại theo Hướng dẫn trỏ tên miền về Hosting cPanel.

Kết

Chống tấn công từ chối dịch vụ ở quy mô website vừa và nhỏ không nằm ở một sản phẩm đắt tiền, mà ở việc dựng sẵn nhiều lớp: một lớp lọc đứng trước, máy chủ gốc không lộ và chỉ nhận lưu lượng từ lớp đó, bộ nhớ đệm toàn trang, tài nguyên tĩnh tách riêng, giới hạn tần suất và kết nối, cùng vài điểm nóng được khoá bớt. Phần lớn công việc phải làm trước khi có sự cố; lúc sự cố chỉ còn là bật thứ đã chuẩn bị và ghi chép lại.

Nếu bạn đang dựng lại hạ tầng cho một dự án và muốn bắt đầu bằng phần gốc — tên miền của chính bạn, DNS sửa được ngay khi cần chuyển hướng khẩn cấp — hãy tra và đăng ký tại ivi.vn/search.

Bạn mua tên miền, mua hosting, làm theo vài hướng dẫn trên mạng rồi gõ tên miền vào trình duyệt — và nhận về trang mặc định của máy chủ, hoặc lỗi “site không truy cập được”. Trỏ tên miền về hosting cPanel chỉ có vài thao tác, nhưng mỗi thao tác đều có một cách sai riêng: sai bản ghi, quên khai báo tên miền phía hosting, hoặc đã đúng hết rồi mà máy bạn vẫn còn nhớ kết quả cũ.

Bài này đi theo đúng thứ tự làm việc thật: chọn cách trỏ, lấy đúng địa chỉ máy chủ, khai báo tên miền trong cPanel, tạo bản ghi, rồi đối chiếu bằng lệnh thay vì đoán. Nếu bạn chưa nắm khái niệm bản ghi DNS, TTL, nameserver là gì, hãy đọc trước bài Hướng dẫn chi tiết cách trỏ tên miền về Landing Page — ở đây chúng ta không giảng lại lý thuyết mà tập trung vào tình huống hosting cPanel.

Hai cách trỏ tên miền về hosting, chọn một

Có đúng hai con đường, và chọn nhầm là nguyên nhân của phần lớn rắc rối về sau. Điểm khác nhau không nằm ở việc cách nào “mạnh” hơn, mà ở chỗ ai là nơi giữ toàn bộ vùng DNS của bạn.

Tiêu chí	Cách 1: Đổi nameserver về hosting	Cách 2: Giữ DNS, chỉ sửa bản ghi A
Bạn phải làm gì	Đổi 2 bản ghi nameserver tại nơi quản lý tên miền	Thêm bản ghi A trỏ về IP máy chủ
Nơi giữ bản ghi	Hosting giữ toàn bộ vùng DNS	Bảng điều khiển tên miền của bạn giữ
Email, xác minh dịch vụ	Phải khai báo lại MX, SPF, DKIM, TXT ở phía hosting	Giữ nguyên, không đụng tới
Khi đổi hosting sau này	Đổi lại nameserver, chờ lan truyền	Sửa một giá trị IP, nhanh hơn
Hợp với ai	Người muốn quản lý tất cả trong cPanel	Người đang dùng email riêng hoặc nhiều dịch vụ gắn với tên miền

Lời khuyên thực dụng: nếu tên miền của bạn đang nhận email hoặc đang có bản ghi xác minh của các dịch vụ khác, hãy chọn cách 2. Đổi nameserver là chuyển cả vùng DNS sang một nơi trắng trơn, và thứ chết đầu tiên luôn là email — vì bản ghi MX không tự đi theo.

Bước 1: Lấy đúng địa chỉ IP của máy chủ

Đăng nhập cPanel, tìm khối thông tin chung — tuỳ giao diện, nó nằm ở cột phải hoặc trong mục Server Information. Bạn cần dòng Shared IP Address (hosting dùng chung) hoặc Dedicated IP Address (nếu bạn có IP riêng). Nếu có IP riêng thì luôn dùng IP riêng.

Ba lưu ý khi lấy IP:

• Copy bằng cách bôi đen chính xác, đừng gõ tay. Một chữ số sai là site trỏ vào máy chủ của người khác chứ không phải báo lỗi rõ ràng.
• Chú ý khoảng trắng thừa ở đầu hoặc cuối khi dán vào ô giá trị bản ghi. Nhiều bảng điều khiển không tự cắt khoảng trắng và sẽ báo “giá trị không hợp lệ” một cách khó hiểu.
• Nếu hosting cung cấp cả địa chỉ IPv6, ghi lại luôn. Bạn sẽ cần nó cho bản ghi AAAA ở bước sau.

Bước 2: Khai báo tên miền bên trong cPanel trước đã

Đây là bước bị bỏ sót nhiều nhất. DNS chỉ đưa người truy cập tới đúng máy chủ; còn việc máy chủ đó biết phải trả về thư mục nào là chuyện của cPanel. Trỏ DNS đúng nhưng chưa khai báo tên miền thì bạn sẽ thấy trang mặc định, trang của tài khoản khác, hoặc thông báo tên miền chưa được cấu hình.

• Nếu đây là tên miền chính của tài khoản hosting: thường nhà cung cấp đã gán sẵn khi tạo tài khoản, thư mục gốc là public_html. Bạn không phải làm gì thêm.
• Nếu bạn thêm tên miền thứ hai vào cùng tài khoản: vào mục Domains (bản cPanel mới) hoặc Addon Domains (bản cũ), nhập tên miền, kiểm tra kỹ ô Document Root. Mặc định cPanel đề xuất một thư mục con trong public_html — hãy đặt tên thư mục dễ nhận ra, vì sau này bạn upload mã nguồn vào đúng chỗ đó.
• Nếu bạn muốn tên miền mới hiển thị cùng nội dung với tên miền cũ: đó là Aliases (parked domain), không phải addon domain.

Khi thêm tên miền, cPanel có thể tự tạo một vùng DNS nội bộ cho tên miền đó. Vùng này chỉ có tác dụng nếu bạn đi theo cách 1 (đổi nameserver). Nếu bạn đi theo cách 2, hãy nhớ nơi quyết định vẫn là bảng điều khiển tên miền của bạn.

Bước 3: Tạo bản ghi tại nơi quản lý DNS

Với tên miền quản lý trong dashboard của ivi.vn, bạn vào phần quản lý DNS của tên miền và thêm các bản ghi sau:

Loại	Tên (host)	Giá trị	Ghi chú
A	@	IP máy chủ hosting	Bắt buộc. @ nghĩa là chính tên miền gốc.
A	www	IP máy chủ hosting	Cách đơn giản và ít lỗi nhất cho tiền tố www.
CNAME	www	tenmiencuaban.com.	Dùng thay cho bản ghi A ở trên, không dùng cả hai.
AAAA	@	IPv6 của máy chủ	Chỉ thêm khi hosting thật sự có IPv6.

Ba quy tắc kỹ thuật cần nhớ, sai là hỏng:

1. Không đặt CNAME ở gốc tên miền. Bản ghi CNAME không được tồn tại song song với bản ghi khác trên cùng một tên, mà gốc tên miền thì luôn có sẵn NS và SOA. Gốc tên miền phải là bản ghi A (hoặc AAAA).
2. Đừng để bản ghi AAAA mồ côi. Nếu tên miền còn bản ghi AAAA trỏ về một máy chủ cũ trong khi hosting mới không có IPv6, người dùng mạng IPv6 sẽ vào nhầm chỗ còn bạn thì thấy site chạy bình thường. Đây là kiểu lỗi “chỉ vài người bị” rất tốn thời gian.
3. Xoá bản ghi cũ trước khi thêm bản ghi mới. Hai bản ghi A cùng tên với hai IP khác nhau không phải là dự phòng, mà là chia đôi lưu lượng ngẫu nhiên giữa hai máy chủ.

Về TTL: trước khi chuyển, hạ TTL của bản ghi cần đổi xuống mức thấp (ví dụ 300 giây) và chờ hết chu kỳ TTL cũ. Làm vậy thì lúc đổi thật, các máy chủ phân giải chỉ giữ giá trị cũ vài phút thay vì vài giờ. Sau khi mọi thứ ổn định thì nâng TTL lên lại.

Bước 4: Đối chiếu sau khi trỏ, đừng dựa vào cảm giác

Cách kiểm tra sai phổ biến nhất là gõ tên miền vào trình duyệt rồi kết luận. Trình duyệt có bộ nhớ đệm riêng, hệ điều hành có bộ nhớ đệm riêng, còn nhà mạng có bộ nhớ đệm riêng nữa. Hãy hỏi thẳng máy chủ DNS công cộng:

# Xem bản ghi A mà một máy chủ DNS công cộng đang trả về
dig +short A tenmiencuaban.com @8.8.8.8
dig +short A www.tenmiencuaban.com @1.1.1.1
# Trên Windows, không có dig thì dùng nslookup
nslookup tenmiencuaban.com 8.8.8.8
# Xem nameserver hiện hành (dùng khi bạn chọn cách 1)
dig +short NS tenmiencuaban.com
# Máy chủ web trả về gì: mã trạng thái và tiêu đề phản hồi
curl -I http://tenmiencuaban.com

Đọc kết quả theo thứ tự này:

• Không ra IP nào: bản ghi chưa được lưu, hoặc bạn sửa nhầm vùng DNS (thường là sửa trong cPanel trong khi tên miền vẫn dùng nameserver cũ).
• Ra IP cũ: còn trong thời gian TTL. Chờ hết TTL cũ rồi kiểm tra lại, đừng sửa thêm gì.
• Ra đúng IP nhưng web sai: DNS đã xong, vấn đề nằm ở bước 2 — tên miền chưa được khai báo trong cPanel, hoặc document root trỏ vào thư mục rỗng.
• Máy bạn vẫn vào chỗ cũ trong khi lệnh dig trả đúng: xoá bộ nhớ đệm DNS của máy, và kiểm tra file hosts xem trước đó bạn có ghim tên miền vào IP nào không.

Khi cần xem tình trạng ở nhiều khu vực, các trang kiểm tra lan truyền DNS trực tuyến là đủ dùng, nhưng hãy coi chúng là tham khảo — kết quả từ chính máy chủ phân giải bạn đang dùng mới là thứ quyết định.

Bước 5: Cấp SSL và dọn phần còn lại

Chỉ sau khi tên miền đã phân giải đúng về IP hosting thì việc cấp chứng chỉ mới thành công, vì quy trình xác minh cần chạm được vào đúng máy chủ đó. Trong cPanel, mục SSL/TLS Status có nút chạy cấp chứng chỉ tự động; nếu bạn tự quản máy chủ thì xem bài Hướng dẫn lấy chứng chỉ SSL Let’s Encrypt để làm bằng dòng lệnh và bật gia hạn tự động.

Vài việc dọn dẹp cuối cùng thường bị quên:

• Chọn một dạng chính thức (có www hoặc không www) rồi chuyển hướng dạng còn lại về đó, tránh hai bản sao cùng tồn tại.
• Với WordPress, đổi địa chỉ site trong phần cài đặt chung sang tên miền mới, và soát lại các đường dẫn tuyệt đối còn ghim tên miền cũ trong nội dung.
• Nếu bạn đã đổi nameserver, kiểm tra lại MX và SPF ngay trong ngày. Email hỏng thường phải một hai hôm sau mới có người phát hiện.
• Ghi lại IP cũ và bản ghi cũ ở đâu đó trước khi xoá, để còn đường lùi.

Bảng kiểm nhanh trước khi bàn giao

Hạng mục	Cách xác nhận
Tên miền gốc phân giải đúng IP	dig +short A tenmien.com @8.8.8.8 trả về IP hosting
Bản www hoạt động	Truy cập được và chuyển hướng đúng về dạng chính thức
Không còn AAAA mồ côi	dig +short AAAA tenmien.com rỗng hoặc trả IPv6 của hosting mới
Website trả về đúng nội dung	curl -I trả mã 200 hoặc 301 về HTTPS
HTTPS hợp lệ	Trình duyệt không cảnh báo, chứng chỉ đúng tên miền
Email còn chạy	Gửi thử một thư vào hộp thư của tên miền

Kết

Trỏ tên miền về hosting cPanel gồm hai nửa và cả hai đều bắt buộc: nửa DNS đưa người truy cập tới đúng máy chủ, nửa cPanel dạy máy chủ trả về đúng thư mục. Chọn cách trỏ theo việc bạn có đang dùng email trên tên miền hay không, hạ TTL trước khi đổi, và luôn đối chiếu bằng lệnh thay vì bằng trình duyệt. Khi thấy IP đúng mà web sai, hãy quay lại phía hosting chứ đừng sửa DNS thêm lần nữa.

Nếu bạn chưa có tên miền để gắn vào hosting, hãy tra và mua trực tiếp tại ivi.vn/search — tên miền mua ở đây quản lý DNS ngay trong dashboard, sửa bản ghi A xong là có thể kiểm tra bằng đúng những lệnh trong bài này.

Ngân sách cho công cụ SEO thường là khoản bị cắt đầu tiên, trong khi công việc thì vẫn phải làm: biết trang nào đang có thứ hạng, trang nào rớt, link nào hỏng, tốc độ tải ra sao. Tin tốt là những dữ liệu quan trọng nhất — dữ liệu do chính công cụ tìm kiếm ghi nhận — đều miễn phí.

Danh sách dưới đây được viết lại cho bối cảnh hiện nay. Các bản miễn phí thay đổi liên tục: có công cụ từng rất hào phóng nay chỉ còn vài lượt tra mỗi ngày. Vì vậy bài này mô tả bản miễn phí làm được việc gì và giới hạn nằm ở đâu, thay vì hứa những con số có thể sai vào tháng sau.

Tiêu chí chọn

• Miễn phí thật, không phải bản dùng thử. Bản dùng thử 7 ngày không giúp bạn theo dõi một website suốt cả năm.
• Dữ liệu gốc được ưu tiên hơn dữ liệu ước lượng. Số lần hiển thị trong công cụ của chính máy tìm kiếm là ghi nhận thật; “lượng tìm kiếm hàng tháng” ở các công cụ bên thứ ba là mô hình ước lượng.
• Còn được cập nhật. Một công cụ ngừng phát triển sẽ dần trả về số liệu lệch mà không báo cho bạn.

1. Google Search Console

Bắt buộc phải có, và nếu chỉ được chọn một công cụ thì chọn cái này. Đây là nơi duy nhất cho bạn biết website thật sự xuất hiện với truy vấn nào, ở vị trí trung bình bao nhiêu, được nhấp bao nhiêu lần.

Việc nên làm ngay sau khi xác minh quyền sở hữu:

• Mở báo cáo hiệu suất, lọc các truy vấn có nhiều lần hiển thị nhưng ít lượt nhấp — đó là những trang chỉ cần sửa tiêu đề và mô tả là có thêm lượt truy cập, không cần viết bài mới.
• Mở báo cáo lập chỉ mục để xem trang nào bị loại và vì lý do gì. “Đã thu thập dữ liệu nhưng chưa lập chỉ mục” là tín hiệu về chất lượng nội dung, không phải lỗi kỹ thuật.
• Nộp sơ đồ trang (sitemap) và kiểm tra ngày đọc gần nhất.
• Dùng công cụ kiểm tra URL để xem máy tìm kiếm nhìn thấy phiên bản nào của trang — thường khác với thứ bạn thấy trên trình duyệt.

Giới hạn: dữ liệu lưu trong khoảng thời gian nhất định và bảng kết quả bị giới hạn số dòng khi xem trực tiếp. Muốn giữ lịch sử dài hơn, hãy xuất dữ liệu định kỳ.

2. Google Analytics 4

Search Console trả lời “người ta tìm gì để tới”, Analytics trả lời “tới rồi thì họ làm gì”. Hai công cụ này liên kết được với nhau và nên liên kết ngay từ đầu.

Với bản miễn phí, ba việc đáng làm trước tiên: đánh dấu các hành động quan trọng thành sự kiện chuyển đổi (gửi biểu mẫu, bấm nút gọi, bấm nút mua); tạo báo cáo so sánh nhóm truy cập từ tìm kiếm tự nhiên với nhóm từ quảng cáo; và gắn tham số theo dõi chiến dịch cho mọi đường dẫn bạn đem đi phát tán, nếu không mọi thứ sẽ dồn hết vào một mục chung chung.

3. Bing Webmaster Tools

Bị bỏ qua một cách vô lý. Nó miễn phí, xác minh nhanh (có thể nhập cấu hình sẵn từ Search Console), và cho vài thứ mà công cụ của Google không cho: gợi ý từ khoá kèm ước lượng lưu lượng, so sánh với đối thủ ở mức cơ bản, và một trình quét kỹ thuật ngay trong giao diện.

Thêm một lý do rất thời sự: nhiều trợ lý trả lời bằng AI lấy kết quả từ chỉ mục của Bing. Có mặt trong chỉ mục đó không còn là chuyện phụ.

4. PageSpeed Insights và dữ liệu trải nghiệm thực

Công cụ này cho hai loại số liệu và đừng nhầm chúng: phần phòng thí nghiệm là một lần đo mô phỏng, còn phần dữ liệu trải nghiệm người dùng thực là tổng hợp từ người truy cập thật trong nhiều tuần. Khi quyết định ưu tiên sửa gì, hãy nhìn phần dữ liệu thực; khi kiểm tra một thay đổi vừa triển khai, hãy nhìn phần mô phỏng vì nó phản hồi ngay.

Ba chỉ số cần nhớ: thời điểm khối nội dung lớn nhất hiển thị xong, độ trễ phản hồi khi người dùng tương tác, và mức xê dịch bố cục trong lúc tải. Website nào cũng nên đo cả bản di động lẫn bản máy tính, vì kết quả thường lệch nhau rất xa.

5. Screaming Frog SEO Spider (bản miễn phí)

Phần mềm cài trên máy, quét website giống cách bot đi và trả về bảng: trang lỗi, chuyển hướng dây chuyền, tiêu đề trùng, thẻ mô tả trống, ảnh thiếu thuộc tính mô tả, thẻ canonical mâu thuẫn. Đây vẫn là cách nhanh nhất để tìm lỗi kỹ thuật trên một website vừa và nhỏ.

Giới hạn của bản miễn phí là số URL quét được trong một lần và một số tính năng nâng cao bị khoá; con số giới hạn có thể thay đổi theo phiên bản nên hãy kiểm tra trước khi lên kế hoạch quét một website lớn. Mẹo dùng: quét theo từng thư mục thay vì cả website, bạn sẽ nằm trong giới hạn mà vẫn đủ dữ liệu để sửa.

6. Google Trends

Không cho con số tuyệt đối, nhưng cho thứ quan trọng hơn với người làm nội dung: hình dạng nhu cầu theo thời gian. Dùng nó để biết chủ đề của bạn có tính mùa vụ không, để so hai cách gọi tên cùng một sản phẩm xem người Việt thực sự gõ cách nào, và để phát hiện một chủ đề đang đi lên hay đã thoái trào trước khi bạn bỏ công viết cả cụm bài.

Nhớ đặt phạm vi về Việt Nam và mở rộng khung thời gian ít nhất 12 tháng, nếu không bạn sẽ đọc nhầm một biến động ngắn hạn thành xu hướng.

7. Bộ công cụ kiểm tra dữ liệu có cấu trúc và kết quả nhiều định dạng

Trình kiểm tra kết quả nhiều định dạng của Google và trình kiểm tra lược đồ của cộng đồng schema.org đều miễn phí, không cần đăng nhập. Dán URL hoặc dán trực tiếp mã, chúng chỉ ra khai báo nào hợp lệ, khai báo nào thiếu trường bắt buộc.

Đây là loại lỗi mắt thường không thấy: trang vẫn hiển thị bình thường, nhưng phần đánh dấu sản phẩm thiếu giá hoặc tình trạng còn hàng thì kết quả tìm kiếm sẽ không hiện phần mở rộng. Sau mỗi lần đổi giao diện hoặc đổi plugin, chạy lại kiểm tra cho một trang đại diện của mỗi loại (trang sản phẩm, bài viết, trang liên hệ).

Bảng tra nhanh: cần gì thì mở cái gì

Bạn cần biết	Mở công cụ
Trang nào đang lên, đang rớt thứ hạng	Google Search Console
Người vào rồi có làm việc bạn muốn không	Google Analytics 4
Ý tưởng từ khoá và mặt trận ngoài Google	Bing Webmaster Tools
Web chậm ở đâu, người dùng thật thấy thế nào	PageSpeed Insights
Link hỏng, thẻ trùng, chuyển hướng vòng	Screaming Frog bản miễn phí
Chủ đề đang lên hay đang xuống	Google Trends
Dữ liệu có cấu trúc còn hợp lệ không	Trình kiểm tra kết quả nhiều định dạng

Những cái tên cũ và lý do không còn nằm trong danh sách

Vài công cụ từng xuất hiện trong mọi bài “SEO miễn phí” nay đã siết bản miễn phí xuống mức chỉ đủ để xem thử: giới hạn vài lượt tra mỗi ngày, che phần lớn dữ liệu, hoặc chuyển hẳn sang thu phí. Chúng vẫn dùng được nếu bạn trả tiền, nhưng không nên là xương sống cho một quy trình miễn phí.

Nguyên tắc chung khi đọc bất kỳ danh sách công cụ nào, kể cả bài này: hãy tự mở trang chủ công cụ và xem bảng gói hiện hành trước khi xây quy trình phụ thuộc vào nó. Số liệu về giới hạn miễn phí là thứ hết hạn nhanh nhất trong mọi bài viết về SEO.

Quy trình 30 phút mỗi tuần với bộ công cụ miễn phí

1. 5 phút: mở Search Console, so sánh 28 ngày gần nhất với kỳ trước. Ghi lại 3 trang giảm mạnh nhất.
2. 10 phút: với 3 trang đó, kiểm tra bằng công cụ kiểm tra URL xem còn được lập chỉ mục không, nội dung có bị thay đổi hay bị trùng với trang khác không.
3. 5 phút: lọc truy vấn nhiều hiển thị ít nhấp, chỉnh lại tiêu đề và mô tả cho 2 trang.
4. 5 phút: chạy PageSpeed Insights cho trang quan trọng nhất ở chế độ di động, ghi lại chỉ số so với tuần trước.
5. 5 phút: mỗi tháng một lần, quét một thư mục bằng Screaming Frog để bắt link hỏng phát sinh.

Việc đều đặn 30 phút quan trọng hơn một buổi tổng rà soát mỗi quý. Phần lớn sự cố SEO đều có dấu hiệu sớm trong Search Console trước khi lưu lượng tụt hẳn.

Kết

Bảy công cụ trên phủ gần hết công việc SEO thường ngày mà không tốn đồng nào: dữ liệu thứ hạng gốc, hành vi người dùng, sức khoẻ kỹ thuật, tốc độ và nhu cầu thị trường. Thứ bạn cần trả không phải tiền mà là thói quen mở chúng đều đặn và ghi lại thay đổi. Khi nào bộ miễn phí bắt đầu chật, đó là lúc doanh thu từ tìm kiếm đã đủ để bạn trả tiền cho công cụ chuyên sâu.

Một điều kiện nền mà không công cụ nào bù được: website phải chạy trên tên miền của chính bạn thì mọi dữ liệu tích luỹ mới thuộc về bạn. Nếu vẫn đang dùng địa chỉ mượn của nền tảng khác, hãy đọc thêm Tại sao Thương hiệu cá nhân cần Tên miền riêng? và tra tên miền tại ivi.vn/search. Nếu bạn đang phân vân giữa một trang bán hàng đơn lẻ và một website nhiều trang, bài So sánh Landing Page và Website truyền thống sẽ giúp bạn chọn trước khi đầu tư công sức SEO.

Chứng chỉ SSL giờ không còn là hạng mục “nên có”. Trình duyệt gắn nhãn cảnh báo cho trang không mã hoá, biểu mẫu bị chặn, và mọi tính năng hiện đại của trình duyệt đều yêu cầu kết nối an toàn. Let’s Encrypt cấp chứng chỉ miễn phí, tự động, nhưng chỉ tự động khi bạn cấu hình đúng ngay từ đầu.

Bài này giải thích cơ chế đằng sau — giao thức ACME, các kiểu xác minh, chu kỳ 90 ngày — rồi mới tới thao tác. Hiểu cơ chế là cách duy nhất để xử lý được lúc gia hạn tự động im lặng thất bại lúc 2 giờ sáng.

ACME: chứng chỉ được cấp bằng cách nào

Let’s Encrypt là một tổ chức cấp chứng chỉ hoạt động hoàn toàn tự động qua giao thức ACME (Automatic Certificate Management Environment). Không có biểu mẫu để điền, không có nhân viên duyệt. Trình tự luôn là:

1. Phần mềm trên máy bạn (ACME client) tạo một cặp khoá tài khoản và đăng ký với tổ chức cấp chứng chỉ.
2. Bạn yêu cầu chứng chỉ cho một danh sách tên miền.
3. Tổ chức cấp chứng chỉ trả về các thử thách (challenge) — mỗi tên miền một thử thách — để chứng minh bạn có quyền kiểm soát tên miền đó.
4. Client đáp ứng thử thách, rồi báo đã sẵn sàng.
5. Máy chủ của tổ chức cấp chứng chỉ đi kiểm tra từ nhiều điểm mạng khác nhau. Đạt thì ký và trả về chứng chỉ.

Điểm mấu chốt: xác minh là quyền kiểm soát tên miền, không phải danh tính doanh nghiệp. Đây là chứng chỉ loại DV. Nó mã hoá đường truyền và xác nhận bạn đang nói chuyện đúng với tên miền đó, chứ không chứng thực công ty phía sau là ai.

HTTP-01 và DNS-01: chọn kiểu xác minh nào

	HTTP-01	DNS-01
Bạn phải làm gì	Đặt một tệp tạm tại /.well-known/acme-challenge/	Tạo bản ghi TXT tên _acme-challenge
Điều kiện	Máy chủ phải mở cổng 80 và truy cập được từ Internet	Có quyền sửa DNS, tốt nhất là sửa được bằng API
Cấp được chứng chỉ ký tự đại diện	Không	Có
Dùng được khi máy chủ nằm sau tường lửa	Không	Có
Độ khó tự động hoá	Rất dễ, client làm hết	Cần trình cắm tương ứng với nơi quản lý DNS

Còn một kiểu thứ ba là TLS-ALPN-01, xác minh ngay trong quá trình bắt tay TLS trên cổng 443. Nó hữu ích khi cổng 80 bị chặn hoàn toàn, nhưng cần phần mềm máy chủ hỗ trợ và ít khi cần tới trong tình huống thông thường.

Quy tắc chọn cho gọn:

• Website bình thường, có IP công khai, mở cổng 80: dùng HTTP-01.
• Cần chứng chỉ ký tự đại diện dạng *.tenmien.com: bắt buộc DNS-01, không có ngoại lệ.
• Máy chủ nội bộ, môi trường thử nghiệm, hoặc muốn cấp chứng chỉ trước khi trỏ tên miền: DNS-01.

Lưu ý về chứng chỉ ký tự đại diện: *.tenmien.com chỉ phủ một cấp tên miền con. Nó bao blog.tenmien.com nhưng không bao a.b.tenmien.com, và cũng không bao chính tenmien.com — muốn đủ thì phải liệt kê cả hai trong cùng một chứng chỉ.

Cách nhanh nhất: hosting có sẵn cơ chế cấp tự động

Nếu bạn dùng hosting chia sẻ với cPanel hoặc bảng điều khiển tương đương, gần như chắc chắn đã có sẵn tính năng cấp chứng chỉ tự động. Vào mục SSL/TLS Status, chọn tên miền, chạy lệnh cấp tự động. Toàn bộ phần gia hạn do máy chủ lo.

Điều kiện để nó chạy được, và cũng là ba lý do phổ biến khiến nó thất bại:

• Tên miền phải đang phân giải về đúng IP máy chủ đó. Chưa trỏ xong thì thử thách không thể đạt. Xem Hướng dẫn trỏ tên miền về Hosting cPanel trước khi bấm cấp chứng chỉ.
• Đường dẫn /.well-known/acme-challenge/ phải truy cập được. Một quy tắc chuyển hướng “bắt tất cả” trong .htaccess hoặc một trình cắm bảo mật chặn thư mục ẩn là đủ để phá hỏng bước này.
• Tên miền con nào không phân giải về máy chủ thì phải loại khỏi danh sách, vì một tên hỏng làm hỏng cả yêu cầu.

Cấp bằng certbot trên máy chủ tự quản

Certbot là client chính thức, phổ biến nhất trên Linux. Hai kiểu dùng:

# Kiểu 1: certbot tự sửa cấu hình máy chủ web
sudo certbot --nginx -d tenmien.com -d www.tenmien.com
# Kiểu 2: chỉ lấy chứng chỉ, bạn tự khai báo trong cấu hình
sudo certbot certonly --webroot -w /var/www/tenmien.com/public 
     -d tenmien.com -d www.tenmien.com
# Thử nghiệm trước bằng môi trường staging để không đụng giới hạn cấp phát
sudo certbot certonly --staging --webroot -w /var/www/tenmien.com/public -d tenmien.com
# Xem các chứng chỉ đang có và ngày hết hạn
sudo certbot certificates

Chứng chỉ được lưu ở /etc/letsencrypt/live/tenmien.com/. Trong cấu hình máy chủ web hãy trỏ tới fullchain.pem (chứng chỉ của bạn kèm chuỗi trung gian) và privkey.pem (khoá riêng). Dùng nhầm cert.pem thay cho fullchain.pem là lỗi kinh điển: trình duyệt máy tính vẫn xanh, nhưng một số ứng dụng di động và công cụ dòng lệnh báo chuỗi chứng chỉ không đầy đủ.

Luôn trỏ tới đường dẫn trong thư mục live/, đừng trỏ vào tệp trong archive/. Thư mục live/ là các liên kết luôn chỉ vào bản mới nhất, nên sau khi gia hạn bạn không phải sửa cấu hình.

acme.sh khi cần DNS-01 tự động

acme.sh là client viết bằng shell, không phụ thuộc môi trường ngôn ngữ khác, và mạnh nhất ở chỗ hỗ trợ rất nhiều nhà quản lý DNS qua API — nghĩa là nó tự tạo và tự xoá bản ghi TXT giúp bạn.

# Cấp chứng chỉ ký tự đại diện bằng DNS-01 (thay dns_xxx bằng trình cắm tương ứng)
acme.sh --issue --dns dns_xxx -d tenmien.com -d '*.tenmien.com'
# Cài chứng chỉ vào đúng chỗ và nạp lại dịch vụ sau mỗi lần gia hạn
acme.sh --install-cert -d tenmien.com 
  --key-file       /etc/ssl/tenmien/privkey.pem 
  --fullchain-file /etc/ssl/tenmien/fullchain.pem 
  --reloadcmd      "systemctl reload nginx"

Nếu nơi quản lý DNS của bạn không có API, vẫn có chế độ tạo bản ghi TXT thủ công — nhưng khi đó bạn phải làm lại bằng tay ở mỗi kỳ gia hạn. Với chứng chỉ 90 ngày, cách thủ công chỉ nên dùng một lần cho tình huống đặc biệt.

Chu kỳ 90 ngày và chuyện gia hạn tự động

Chứng chỉ Let’s Encrypt có hiệu lực 90 ngày. Đây là lựa chọn có chủ đích: vòng đời ngắn buộc mọi người phải tự động hoá, và giới hạn thiệt hại nếu khoá riêng bị lộ. Thông lệ là gia hạn khi còn khoảng 30 ngày, tức vào khoảng ngày thứ 60 — như vậy bạn còn cả tháng đệm để xử lý nếu có trục trặc.

Cả certbot lẫn acme.sh đều tự cài sẵn tác vụ định kỳ khi cài đặt, và lệnh gia hạn chỉ thực sự làm việc khi chứng chỉ đã tới ngưỡng. Vì vậy chạy lệnh gia hạn hằng ngày là bình thường và không hề lãng phí.

# Diễn tập gia hạn: chạy toàn bộ quy trình nhưng không thay chứng chỉ thật
sudo certbot renew --dry-run
# Kiểm tra tác vụ định kỳ có đang bật không
systemctl list-timers | grep -i certbot
# Xem ngày hết hạn thực tế mà máy chủ đang phục vụ
echo | openssl s_client -servername tenmien.com -connect tenmien.com:443 2>/dev/null 
  | openssl x509 -noout -dates

Câu lệnh cuối quan trọng hơn hai câu trên: nó hỏi thẳng cổng 443 xem chứng chỉ đang được phục vụ hết hạn ngày nào. Tình huống hay gặp nhất không phải là gia hạn thất bại, mà là gia hạn thành công nhưng dịch vụ chưa được nạp lại nên vẫn giữ chứng chỉ cũ trong bộ nhớ. Luôn khai báo lệnh nạp lại dịch vụ trong móc sau gia hạn.

Đừng trông chờ vào email nhắc hết hạn từ bên cấp chứng chỉ. Hãy tự đặt một phép giám sát định kỳ kiểm tra số ngày còn lại và báo cho bạn khi xuống dưới ngưỡng — đó là cách duy nhất bạn biết trước thay vì biết khi khách gọi điện.

Bảy lỗi khiến việc cấp hoặc gia hạn thất bại

• Cổng 80 bị đóng. HTTP-01 cần cổng 80. Bạn có thể chuyển hướng toàn bộ sang HTTPS, vì quy trình xác minh đi theo chuyển hướng, nhưng không được chặn hẳn cổng 80 ở tường lửa.
• Chặn nhầm thư mục thử thách. Quy tắc viết lại đường dẫn của ứng dụng nuốt luôn /.well-known/acme-challenge/. Hãy thêm ngoại lệ cho đường dẫn này trước mọi quy tắc khác.
• Chặn theo vùng địa lý. Máy chủ xác minh đi từ nhiều điểm trên thế giới. Nếu bạn chỉ cho phép truy cập từ Việt Nam, phần lớn các điểm kiểm tra sẽ bị chặn và thử thách trượt.
• Bản ghi DNS chưa lan truyền. Với DNS-01, TTL cao khiến bản ghi TXT mới chưa thấy được lúc kiểm tra. Hạ TTL của vùng DNS xuống thấp trước khi tự động hoá.
• Đụng giới hạn cấp phát. Mỗi tên miền có hạn mức số lần cấp trong một khoảng thời gian. Khi đang thử cấu hình, luôn dùng môi trường staging; chỉ chuyển sang thật khi đã chạy trơn.
• Đồng hồ hệ thống sai. Lệch giờ nhiều làm chứng chỉ bị coi là chưa có hiệu lực hoặc đã hết hạn. Bật đồng bộ thời gian trên máy chủ.
• Bật HSTS quá sớm. HSTS ra lệnh cho trình duyệt chỉ được kết nối bằng HTTPS trong khoảng thời gian dài. Bật khi chứng chỉ chưa ổn định là tự khoá mình ra ngoài. Hãy chạy HTTPS trơn tru vài tuần rồi mới bật, và bắt đầu bằng thời hạn ngắn.

Sau khi có chứng chỉ thì làm gì tiếp

1. Chuyển hướng toàn bộ HTTP sang HTTPS bằng mã 301, trừ đường dẫn thử thách ACME.
2. Soát nội dung hỗn hợp: ảnh, tệp CSS và JavaScript còn gọi bằng http:// sẽ làm mất biểu tượng an toàn. Công cụ dành cho nhà phát triển của trình duyệt liệt kê đủ danh sách này.
3. Kiểm tra chuỗi chứng chỉ bằng một công cụ đánh giá cấu hình TLS trực tuyến, xem có thiếu chứng chỉ trung gian không.
4. Đặt giám sát ngày hết hạn cho mọi tên miền, kể cả tên miền phụ ít dùng — chúng chính là những cái hết hạn mà không ai biết.
5. Có HTTPS rồi thì tính tiếp tới chuyện chịu tải và chống lạm dụng: xem Kỹ thuật chống DDoS cơ bản khi quản trị Web.

Kết

Let’s Encrypt cấp chứng chỉ DV miễn phí qua giao thức ACME, xác minh bằng HTTP-01 hoặc DNS-01, hiệu lực 90 ngày và mặc định là phải tự động hoá. Chọn HTTP-01 cho website thông thường, DNS-01 khi cần chứng chỉ ký tự đại diện hoặc máy chủ không lộ ra Internet. Việc quan trọng nhất không phải lần cấp đầu tiên mà là chứng minh được rằng lần gia hạn thứ hai sẽ tự chạy: hãy diễn tập gia hạn, khai báo lệnh nạp lại dịch vụ, và giám sát ngày hết hạn từ bên ngoài.

Đang tìm tên miền cho dự án mới và muốn chạy HTTPS ngay từ ngày đầu? Tra và đăng ký tại ivi.vn/search, sửa bản ghi DNS ngay trong dashboard rồi cấp chứng chỉ theo đúng các bước ở trên.

Câu hỏi “nên làm landing page hay làm website” thường được trả lời bằng ngân sách, trong khi nó là câu hỏi về mục tiêu. Chọn sai thì tiền vẫn mất mà kết quả không tới: một trang bán hàng đơn lẻ không bao giờ tích luỹ được lưu lượng tìm kiếm, còn một website đầy đủ dựng vội cho chiến dịch quảng cáo hai tuần thì gần như chắc chắn lỗ công.

Bài này so sánh theo hai trục mà người quyết định thật sự quan tâm: mục tiêu bạn đang theo đuổi và chi phí duy trì sau khi bàn giao. Không có bên nào thắng tuyệt đối; có bên phù hợp với việc bạn đang làm trong quý này.

Định nghĩa lại cho đúng: khác nhau ở mục tiêu, không ở số trang

Nhiều người định nghĩa landing page là “trang một cột dài” và website là “trang có menu”. Cách phân biệt đó sai ở chỗ nó mô tả hình thức. Đúng hơn:

• Landing page là trang được thiết kế cho một hành động duy nhất. Mọi thành phần trên trang, kể cả việc lược bỏ menu điều hướng, đều nhằm giữ người đọc đi tới hành động đó: điền biểu mẫu, gọi điện, đặt hàng, tải tài liệu.
• Website là nơi chứa nhiều loại nội dung phục vụ nhiều nhóm người ở nhiều giai đoạn khác nhau: người mới biết tới bạn, người đang so sánh, khách cũ đi tìm hướng dẫn, ứng viên xin việc, nhà báo tìm thông tin liên hệ.

Hệ quả: một website có thể chứa nhiều landing page bên trong nó. Và một landing page tồn tại lâu năm với nội dung được cập nhật liên tục sẽ dần biến thành một website nhỏ. Ranh giới là chức năng, không phải cấu trúc tệp.

Bảng đối chiếu

Tiêu chí	Landing page	Website truyền thống
Mục tiêu chính	Chuyển đổi một hành động cụ thể	Xây dựng hiện diện và niềm tin lâu dài
Điều hướng	Cố tình rút gọn hoặc bỏ hẳn	Có menu, phân cấp danh mục
Nguồn truy cập chủ yếu	Quảng cáo, tin nhắn, mã QR, liên kết trong tiểu sử	Tìm kiếm tự nhiên, truy cập trực tiếp, liên kết từ nơi khác
Vòng đời	Theo chiến dịch, vài tuần đến vài tháng	Nhiều năm, cập nhật liên tục
Chỉ số đánh giá	Tỷ lệ chuyển đổi, chi phí trên mỗi khách hàng tiềm năng	Lưu lượng tự nhiên, số trang có thứ hạng, khách quay lại
Thời gian dựng	Nhanh, có thể trong ngày	Lâu hơn, phụ thuộc lượng nội dung và tính năng
Chi phí ban đầu	Thấp, đôi khi chỉ là công viết nội dung	Cao hơn, gồm thiết kế, nội dung, tính năng
Chi phí duy trì	Thấp khi đang chạy, gần như bằng không khi dừng	Đều đặn: cập nhật, sao lưu, bảo mật, nội dung mới
Giá trị tích luỹ	Gần như không tích luỹ, dừng quảng cáo là dừng khách	Tích luỹ, nội dung cũ vẫn kéo khách sau nhiều tháng
Rủi ro lớn nhất	Phụ thuộc hoàn toàn vào ngân sách quảng cáo	Bỏ bê giữa chừng, thành website chết

Chi phí duy trì thật sự gồm những gì

Đây là phần hay bị bỏ sót khi so sánh, vì báo giá thường chỉ nói tới chi phí dựng. Hãy tính đủ theo năm:

Khoản chung cho cả hai

• Tên miền: trả theo năm, và nên trả cho tên miền của chính bạn thay vì dùng địa chỉ mượn của một nền tảng. Toàn bộ uy tín tích luỹ nằm ở tên miền.
• Nơi lưu trữ: hosting hoặc máy chủ, cũng theo năm.
• Chứng chỉ bảo mật: có thể miễn phí nhưng phải bảo đảm gia hạn tự động chạy đều.

Khoản chỉ website mới có

• Cập nhật nền tảng và trình cắm: việc lặp lại hằng tháng. Bỏ qua đủ lâu thì rủi ro bảo mật tăng dần, và một ngày nào đó bản cập nhật lớn không còn tương thích với giao diện cũ.
• Sao lưu và khôi phục: phải kiểm tra khôi phục thật, không chỉ tin rằng bản sao lưu tồn tại.
• Nội dung mới: khoản tốn nhất và hay bị tính bằng không vì “tự viết”. Công sức vẫn là chi phí.
• Sửa lỗi phát sinh: link hỏng, biểu mẫu ngừng gửi thư, trang chậm dần khi dữ liệu phình.

Khoản chỉ landing page mới có

• Ngân sách quảng cáo: landing page không tự có khách. Nếu chưa tính khoản này thì bảng so sánh chi phí đang lệch hoàn toàn.
• Chi phí làm lại theo chiến dịch: mỗi đợt sản phẩm mới thường cần một trang mới, hoặc ít nhất một bản viết lại.
• Phí nền tảng dựng trang: nếu dùng công cụ kéo thả trả phí, đây là khoản định kỳ.

Đặt cạnh nhau: website đắt ở giai đoạn đầu và tốn công duy trì đều đặn, nhưng phần đã làm vẫn sinh giá trị khi bạn ngừng bỏ tiền. Landing page rẻ khi dựng nhưng chi phí thật nằm ở dòng ngân sách quảng cáo, và giá trị dừng lại đúng lúc bạn tắt quảng cáo.

Chọn landing page khi nào

• Bạn đang chạy một chiến dịch có thời hạn: ra mắt sản phẩm, khuyến mại theo mùa, tuyển sinh một khoá học.
• Nguồn khách đã có sẵn từ quảng cáo hoặc mạng xã hội, việc còn lại chỉ là chốt.
• Bạn cần kiểm chứng một ý tưởng trước khi đầu tư lớn. Một trang cộng một khoản quảng cáo nhỏ cho câu trả lời nhanh hơn nhiều so với dựng cả website rồi mới biết thị trường không mặn mà.
• Bạn muốn đo lường sạch: một trang, một mục tiêu, một con số để so.

Chọn website khi nào

• Khách của bạn tìm giải pháp bằng cách tra cứu trước khi mua, và bạn muốn có mặt trong lúc họ tra.
• Sản phẩm hoặc dịch vụ cần được giải thích nhiều, có nhiều nhóm khách khác nhau.
• Bạn cần một nơi đáng tin để đối tác, ứng viên, nhà cung cấp kiểm chứng bạn là ai.
• Bạn tính chuyện dài, chấp nhận vài tháng đầu ít khách để đổi lấy nguồn truy cập không phải trả tiền về sau. Bộ công cụ theo dõi cho giai đoạn này có thể hoàn toàn miễn phí, xem Top 7 công cụ SEO miễn phí không thể thiếu.

Cách phổ biến nhất trong thực tế: dùng cả hai

Phần lớn đơn vị làm ăn ổn định không chọn một bên. Họ có website làm trục chính và tạo landing page riêng cho từng chiến dịch, đặt trên tên miền con hoặc thư mục con của cùng tên miền. Cách bố trí này có ba cái lợi cụ thể:

1. Uy tín tên miền dùng chung, người xem không thấy lạ khi chuyển từ quảng cáo sang trang bán hàng.
2. Cấu hình đo lường khai báo một lần, dùng cho cả hai.
3. Landing page hết chiến dịch có thể chuyển hướng về một trang phù hợp trong website, thay vì để lại một địa chỉ chết.

Trình tự nên đi: bắt đầu bằng landing page để kiểm chứng nhu cầu và có doanh thu sớm, dùng chính doanh thu đó nuôi website dài hạn. Ngược lại — dựng website hoành tráng trước khi biết có ai mua không — là cách tiêu tiền phổ biến nhất và cũng tiếc nhất.

Về mặt kỹ thuật, cả hai đều bắt đầu từ một việc giống nhau: trỏ tên miền về nơi đang chứa trang. Nếu bạn dùng nền tảng dựng trang bên ngoài, xem Hướng dẫn chi tiết cách trỏ tên miền về Landing Page; nếu bạn dùng hosting riêng, xem Hướng dẫn trỏ tên miền về Hosting cPanel.

Sai lầm hay gặp ở cả hai phía

• Landing page nhồi thêm menu đầy đủ. Mỗi liên kết thêm vào là một lối ra khỏi mục tiêu chuyển đổi. Nếu đã cần menu, thứ bạn cần là website.
• Website không có trang nào để chốt. Có blog, có giới thiệu, nhưng người đọc muốn mua thì không biết bấm vào đâu.
• Đặt landing page trên một tên miền hoàn toàn khác cho mỗi chiến dịch. Uy tín bị chia nhỏ, và sau vài chiến dịch bạn có một đống tên miền phải nhớ gia hạn.
• Không đo gì cả. Không có số chuyển đổi thì mọi tranh luận “landing page hay website” chỉ là cảm tính.
• Bỏ trang cũ nằm im. Chiến dịch kết thúc mà trang vẫn còn giá cũ, khuyến mại đã hết — khách vào thấy sẽ mất niềm tin.

Bốn câu hỏi để quyết trong 15 phút

1. Trong 30 ngày tới, bạn muốn người truy cập làm đúng một việc gì? Trả lời được ngay và chỉ một việc thì nghiêng về landing page.
2. Khách của bạn có tra cứu trước khi mua không? Có thì bạn cần nội dung dài hạn, tức là website.
3. Bạn có ngân sách quảng cáo đều đặn không? Không có mà vẫn làm landing page thì trang sẽ không có ai vào.
4. Ai sẽ cập nhật nó sau ba tháng nữa? Không có câu trả lời thì đừng dựng website nhiều trang, hãy bắt đầu nhỏ.

Kết

Landing page và website không thay thế nhau: một bên chốt nhanh trong một chiến dịch, một bên tích luỹ giá trị qua nhiều năm. Chi phí ban đầu chỉ là một nửa bức tranh — hãy so cả chi phí duy trì, trong đó ngân sách quảng cáo là khoản duy trì thật sự của landing page, còn cập nhật và nội dung mới là khoản duy trì của website. Cách đi ít rủi ro nhất là kiểm chứng bằng một trang trước, rồi mở rộng thành website khi đã biết ai đang mua và mua vì lý do gì.

Dù chọn hướng nào, bước đầu tiên vẫn là một tên miền đứng tên bạn để mọi thứ tích luỹ về một chỗ. Tra tên miền và bắt đầu tại ivi.vn/search.