Server mới đã sẵn sàng, nhưng domain vẫn trỏ về server cũ. Muốn kiểm tra virtual host và chứng chỉ trước khi chuyển lưu lượng, không nhất thiết phải sửa DNS công khai hoặc hosts trên cả máy. curl có thể dùng ánh xạ địa chỉ riêng cho một lần chạy.
Bài viết dùng app.example.com và IP tài liệu 203.0.113.10 làm ví dụ, không phải đích có thể dùng để kiểm thử dịch vụ thật. Thay bằng hostname và server thuộc phạm vi được phép kiểm tra. Các lệnh minh họa chưa được dùng để thực hiện migration hay thay đổi DNS production.
1. Vì sao mở URL bằng IP chưa kiểm tra đúng website?
Một IP có thể phục vụ nhiều website. Tên trong URL tham gia chọn virtual host, TLS SNI và xác minh danh tính chứng chỉ. Truy cập https://203.0.113.10 không tương đương truy cập https://app.example.com qua IP đó.
Chỉ thêm header Host khi URL vẫn là IP cũng không tái tạo đầy đủ hành vi TLS theo hostname. Everything curl — Name resolve tricks giải thích sự khác biệt giữa việc đổi header và dùng --resolve.
Trước khi thử, ghi rõ điều cần chứng minh: server mới phục vụ đúng hostname, chuỗi chứng chỉ được tin cậy và route cần chuyển trả đúng nội dung. Một trang mặc định trả 200 không đủ đáp ứng cả ba mục tiêu.
2. Giữ hostname trong URL, chỉ đổi địa chỉ kết nối
curl --resolve "app.example.com:443:203.0.113.10" --connect-timeout 5 --max-time 15 -sS -D - -o /dev/null "https://app.example.com/"Ánh xạ có ba phần: hostname, port và địa chỉ. Nó phải khớp tên/port đang được truy cập. URL vẫn giữ app.example.com; đây là điểm quan trọng để kiểm tra website theo tên. Tham khảo curl manual, --resolve.
Ví dụ dành cho shell Linux/macOS: -D - in response header, còn -o /dev/null bỏ body khỏi màn hình. Trên Windows PowerShell, gọi curl.exe để chắc chắn dùng curl executable; thay /dev/null bằng NUL nếu chạy cùng kiểu lệnh đó.
Hai timeout giúp phép thử có thời hạn. Chúng không phải cấu hình nên sao chép nguyên xi vào mọi bài đo hiệu năng; hãy chọn giới hạn theo môi trường và mục tiêu kiểm tra.
3. Xác minh chứng chỉ theo đúng mô hình tin cậy
curl mặc định xác minh chứng chỉ của server. Nếu gặp lỗi, kiểm tra tên được cấp, hạn dùng, chuỗi trung gian và trust store của client. Với hệ thống dùng CA nội bộ, có thể chỉ định CA bundle đã được xác minh:
curl --cacert ./company-ca.pem --resolve "app.example.com:443:203.0.113.10" "https://app.example.com/"Tài liệu xác minh chứng chỉ của curl mô tả trust store và --cacert. Không lấy file CA tùy ý từ một nguồn chưa kiểm chứng chỉ để làm lệnh hết lỗi. Kết quả chạy với -k/--insecure không chứng minh người dùng thật sẽ vượt qua xác minh TLS.
Nếu origin được thiết kế chỉ cho CDN truy cập, có mTLS hoặc trust model riêng, thử trực tiếp từ laptop có thể thất bại đúng theo thiết kế. Khi đó cần xác định đường kiểm thử phù hợp thay vì mở quyền mạng hoặc đổi cấu hình tin cậy ngoài kế hoạch.
4. Kiểm tra redirect trước khi tự động đi tiếp
Bắt đầu không có -L để thấy status và Location. Nếu response chuyển sang www.example.com, ánh xạ app.example.com không tự áp dụng cho hostname mới. Lệnh follow redirect có thể rời server đang kiểm tra và quay lại hạ tầng cũ.
Lập danh sách từng hop: scheme, hostname, port và đường dẫn. Nếu chủ động dùng -L, chỉ thêm ánh xạ cho các tên thuộc phạm vi kiểm thử và xác minh từng đích. Không dùng việc “cuối cùng mở được một trang” làm bằng chứng server mới phục vụ toàn bộ luồng.
5. Proxy và CDN có thể thay đổi ý nghĩa kết quả
Kiểm tra cấu hình proxy của máy chạy lệnh. Khi request đi qua proxy, không nên mặc định ánh xạ cục bộ có tác động như một kết nối trực tiếp. Với phép thử trực tiếp đã được cho phép, tùy chọn --noproxy có thể giới hạn bỏ proxy cho hostname cụ thể:
curl --noproxy "app.example.com" --resolve "app.example.com:443:203.0.113.10" "https://app.example.com/"Đường trực tiếp không kiểm tra WAF, cache, rule chuyển hướng hay chứng chỉ ở CDN edge. Hãy tách biên bản “origin đúng” và “luồng public đúng”, sau đó kiểm tra đường public khi triển khai. Tránh gọi trực tiếp endpoint có tác dụng ghi để thử routing nếu chưa chuẩn bị dữ liệu và quyền thực hiện.
6. Đọc nội dung và bằng chứng triển khai
Sau header, kiểm tra body của một route đọc có tính đại diện. Có thể dùng version marker không nhạy cảm của bản build, tiêu đề trang hoặc trường JSON dự kiến. Không đưa secret hay toàn bộ environment vào health endpoint chỉ để dễ phân biệt hai server.
| Quan sát | Điều chưa được chứng minh |
|---|---|
| HTTP 200 | Chưa chắc đúng virtual host hoặc phiên bản build |
| TLS hợp lệ | Chưa chắc database, storage hay queue hoạt động đúng |
| Origin trực tiếp hoạt động | Chưa kiểm tra CDN, proxy hoặc cache public |
| Một route thành công | Chưa chứng minh mọi hostname, redirect và tính năng đều đúng |
Trong script tự động, kiểm tra riêng exit code của curl và HTTP status: mặc định nhận một HTTP error không nhất thiết làm curl trả exit code lỗi. Đồng thời assert nội dung mong muốn để tránh “pass” khi nhận trang lỗi được bọc trong response 200.
7. Checklist trước và sau đổi DNS
- Ghi hostname, IP mới, port, proxy và mục tiêu của phép thử.
- Dùng URL có hostname thật và ánh xạ đúng host:port.
- Xác minh TLS theo trust model dự kiến, không dựa vào -k.
- Kiểm tra status, redirect và nội dung nhận diện bản build.
- Thử các route đọc chính, rồi kiểm thử nghiệp vụ riêng trong môi trường phù hợp.
- Sau đổi DNS, chạy lại không có --resolve từ đường public và theo dõi lỗi.
- Giữ phương án rollback cùng dữ liệu quan sát; thành công cục bộ không bảo đảm mọi cache DNS đã đổi.
--resolve giúp tách bài toán “server mới có đúng không?” khỏi “DNS hiện đang trỏ đâu?”. Dùng nó để tạo bằng chứng trước cutover, rồi hậu kiểm đường public để xác nhận trải nghiệm thật của người dùng.
Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.