Varnish Cache proxy: cache nội dung công khai đúng cách

Varnish Cache proxy giúp lưu phản hồi dùng chung trước ứng dụng, nhưng cần chính sách rõ để không phục vụ nhầm nội dung theo phiên. ProxyVN cùng anh em xây dựng một lab chỉ cache nội dung công khai, theo dõi hit và miss, kiểm tra cookie cùng Authorization rồi lập quy trình cập nhật dữ liệu mà không biến cache thành proxy đổi IP.

Varnish Cache proxy đứng trước ứng dụng cần giảm tải

Varnish thường được triển khai ở phía nhận request cho website hoặc API, trước backend cung cấp nội dung. Nó có thể dùng lại phản hồi đã lưu khi điều kiện phù hợp, nhờ đó giảm những request phải xử lý lại ở backend. Vai trò này khác forward proxy phục vụ đường ra của client. Cài Varnish trước website không tự cấp một kho IP trung gian cho công cụ thu thập dữ liệu.

Trong mô hình bài viết, client thử gửi request tới Varnish rồi Varnish kết nối backend nội dung trên cùng host. Backend có tài nguyên công khai dưới /public/ và tài nguyên yêu cầu phiên ở đường khác. Đây là lab giả định để kiểm tra chính sách cache. Không có kết quả giảm tải, tỷ lệ hit hoặc tốc độ thương mại nào được đưa ra như số đo đã thực hiện.

Chọn nội dung dùng chung trước

Một tài nguyên phù hợp cho cache dùng chung phải có cùng ý nghĩa với các người đọc thuộc phạm vi đã xác định. Trang sản phẩm công khai có thể khác trang giỏ hàng hoặc thông tin tài khoản. Cùng trả mã 200 chưa nói chúng có thể dùng chung phản hồi. Đội ứng dụng cần phân loại nội dung trước khi người vận hành hạ tầng thêm quy tắc để tăng tỷ lệ hit.

RFC 9111 về HTTP caching cung cấp cơ sở cho việc lưu và dùng lại phản hồi theo các trường điều khiển cache. Trong thực tế triển khai, chính sách ứng dụng và cấu hình Varnish cần phối hợp. Một chỉ thị ở backend có thể bị cấu hình tùy chỉnh thay đổi ý nghĩa nếu người viết VCL bỏ qua nó. Vì vậy, phải kiểm tra cả response lẫn đường xử lý thực tế.

Phân biệt hiệu quả cache với thay đường kết nối

Một hit nhanh không chứng minh nguồn IP có chất lượng cao hơn, vì nội dung có thể được trả từ bản lưu gần client hơn thay vì lấy mới từ backend. Khi benchmark website, cần ghi trạng thái cache. Nếu so hit với miss rồi gọi khác biệt đó là hiệu năng đường proxy, kết luận sẽ trộn hai cơ chế. Bài này tập trung vào tính đúng của lưu dùng chung trước khi đánh giá tốc độ.

Với nhu cầu IP đường ra độc lập cho ứng dụng, anh em có thể tham khảo mua proxy sau khi xác định giao thức; Varnish trong bài phục vụ cache phía website, không thay cho chức năng đó.

Varnish Cache proxy cần phân loại trạng thái request

Request có cookie hoặc Authorization có thể gắn với người dùng, nhưng ý nghĩa cụ thể do ứng dụng quyết định. Một cookie phân tích không nhất thiết làm nội dung cá nhân hóa, còn một header tùy chỉnh có thể thay đổi nội dung dù không có cookie. Chính sách lab chọn hướng bảo thủ: gặp cookie hoặc Authorization thì không dùng cache chung. Việc tối ưu sâu hơn cần hợp đồng ứng dụng riêng.

Không xóa cookie hàng loạt để tăng hit

Xóa toàn bộ Cookie header có thể làm request mất trạng thái mà ứng dụng đang cần. Trang giỏ hàng, ngôn ngữ, quyền truy cập hoặc giá theo nhóm có thể bị thay đổi ngoài dự kiến. Trước khi bỏ một cookie ở khu vực công khai, cần biết nó dùng cho mục đích nào và có ảnh hưởng response không. Không dùng tên nghe giống analytics làm bằng chứng duy nhất để quyết định xóa.

Phân loại trước khi cache

Mặt khác, giữ mọi cookie cũng có thể làm tài nguyên công khai luôn pass, giảm hiệu quả cache. Đây là đánh đổi cần được đo trên ứng dụng cụ thể, không phải lỗi phải sửa bằng một quy tắc chung. Bắt đầu với chính sách an toàn về phạm vi, kiểm tra nội dung đúng rồi mới tối ưu từng nhóm cookie đã được xác nhận. Mỗi thay đổi cần một tình huống kiểm tra đối chiếu.

Tài nguyên công khai cần có hợp đồng rõ

Đường /public/ trong lab không tự làm nội dung thành công khai. Backend phải bảo đảm tài nguyên ở đó không dùng phiên để trả dữ liệu riêng hoặc quyền khác nhau. Nếu cùng URL có phiên bản theo ngôn ngữ hay định dạng, cần mô tả biến thể bằng cơ chế phù hợp. Tên đường dẫn chỉ là điều kiện chọn của cấu hình, không phải bằng chứng về tính chất dữ liệu.

Kiểm tra cả trạng thái từ response

Backend có thể phát Set-Cookie trong một response tưởng như công khai, chẳng hạn để khởi tạo phiên. Cấu hình nhận request không đủ để nhận biết điều này trước. Cần xem chính sách ở giai đoạn backend response và giữ những điều kiện built-in có liên quan. Một lớp cache chỉ kiểm tra URL mà bỏ qua response có thể dùng lại nội dung không phù hợp dù phần request nhìn có vẻ đơn giản.

Varnish Cache proxy với TTL và khóa cache có giới hạn

TTL cho biết khoảng thời gian phản hồi được xem là còn tươi theo chính sách áp dụng. Nó không bảo đảm dữ liệu không đổi trong khoảng đó. Nếu một nội dung được cập nhật ngay sau khi cache được tạo, người đọc có thể nhận bản cũ cho tới khi cơ chế làm mới hoặc vô hiệu hóa có tác dụng. Phạm vi chấp nhận dữ liệu cũ cần được ứng dụng xác định trước.

Đọc Cache-Control theo đúng chỉ thị

Tài liệu Cache-Control của MDN phân biệt các chỉ thị liên quan lưu và dùng lại phản hồi. private, no-store và no-cache không phải ba cách viết cùng một điều kiện. Khi cấu hình lab chọn không lưu dùng chung các response chứa những chỉ thị đó, đó là chính sách giới hạn của ví dụ, không phải định nghĩa thay thế cho chuẩn HTTP.

Nếu backend có max-age hoặc s-maxage phù hợp, nên giữ ý nghĩa và chỉ đặt trần TTL khi có yêu cầu rõ. Không nên ghi đè mọi response thành một TTL dài để biểu đồ hit tăng. Giá trị hit cao có thể đi kèm dữ liệu cũ hoặc sai phạm vi. Tính đúng của nội dung và quyền truy cập cần được đặt trước một chỉ số tổng dễ nhìn.

Khóa cache phải phản ánh các khác biệt cần thiết

Một URL giống nhau có thể trả khác theo host, ngôn ngữ hoặc định dạng được thương lượng. Cần hiểu khóa cache và những biến thể ứng dụng tạo ra trước khi tùy chỉnh hash. Nếu bỏ Host hoặc một biến thể quan trọng, dữ liệu từ một ngữ cảnh có thể được dùng cho ngữ cảnh khác. Nếu đưa quá nhiều giá trị không cần thiết vào khóa, hiệu quả cache lại giảm do chia nhỏ đối tượng.

Trong lab này không tự viết vcl_hash, để tránh vô tình tạo một khóa rút gọn không đủ điều kiện. Khi triển khai nhiều tenant, hãy thử hai tenant với cùng đường dẫn và nội dung nhận biết riêng trong môi trường thử. Nếu chúng nhận nhầm dữ liệu, đó là lỗi tính đúng cần xử lý trước. Đổi TTL hoặc purge liên tục không sửa được một khóa cache thiết kế sai.

Giữ query string theo hợp đồng ứng dụng

Tham số truy vấn có thể quyết định nội dung, bộ lọc hoặc quyền được yêu cầu. Không xóa tất cả query để gộp cache chỉ vì chúng làm số đối tượng tăng. Nếu có tham số chỉ phục vụ đo lường, việc bỏ nó cần được xác nhận với ứng dụng. Trong một bài thử, dùng hai URL khác tham số có kết quả kỳ vọng khác để chắc rằng tối ưu không làm chúng bị gộp sai.

Varnish Cache proxy qua cấu hình lab công khai

Khung VCL sau do người viết tổ chức để giới hạn phạm vi thử. Nó dùng cú pháp VCL 4.1, backend HTTP tại loopback cổng 8081 và chỉ xét GET hoặc HEAD dưới /public/. Những request có trạng thái phiên được pass về backend. Cấu hình chưa tạo backend và chưa triển khai TLS đầu vào; cần chuẩn bị các thành phần đó riêng trong lab được quản lý.

vcl 4.1;
 
backend default {
    .host = "127.0.0.1";
    .port = "8081";
}
 
sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.http.Authorization || req.http.Cookie ||
        req.http.Cache-Control) {
        return (pass);
    }
    if (req.url !~ "^/public/") {
        return (pass);
    }
    return (hash);
}

Mã built-in VCL của dự án Varnish cho thấy luồng mặc định và cách các subroutine tùy chỉnh tương tác với nó. Một return trong VCL của mình có thể dừng trước phần built-in tương ứng. Vì vậy, không thể thêm return tùy ý rồi vẫn giả định mọi kiểm tra mặc định phía sau sẽ tiếp tục. Đọc đúng phiên bản cài đặt trước khi triển khai.

Bổ sung kiểm tra response vào cùng tệp

Phần dưới được nối vào tệp lab.vcl sau khối trước. Nó chỉ xét cache response thành công đã khai báo public và loại những dấu hiệu trạng thái không phù hợp với cache chung của lab. TTL bị giới hạn tối đa ba mươi giây, grace đặt bằng không để bài thử không trộn thêm việc phục vụ nội dung cũ khi backend lỗi. Đây là chính sách minh họa, cần điều chỉnh theo yêu cầu thực tế.

sub vcl_backend_response {
    if (beresp.status != 200 || beresp.http.Set-Cookie ||
        beresp.http.Cache-Control !~ "(?i)(^|,)[ ]*public([ ,]|$)" ||
        beresp.http.Cache-Control ~ "(?i)(private|no-store|no-cache)" ||
        beresp.http.Vary == "*") {
        set beresp.uncacheable = true;
        set beresp.ttl = 0s;
        return (deliver);
    }
    if (beresp.ttl > 30s) {
        set beresp.ttl = 30s;
    }
    set beresp.grace = 0s;
}

Nhánh còn lại không return ở cuối để những xử lý built-in của phiên bản tiếp tục theo cơ chế VCL. Biểu thức kiểm tra header trong ví dụ không phải một bộ phân tích Cache-Control tổng quát cho mọi cách biểu diễn. Dùng backend lab có header rõ như public, max-age=20 để kiểm tra trước. Không mang cấu hình thử này lên toàn bộ ứng dụng nhiều loại dữ liệu mà chưa duyệt chính sách.

VCL lab có phạm vi hẹp

Kiểm tra cú pháp khác với kiểm tra hành vi

Với môi trường đã có Varnish, có thể dùng varnishd -C -f lab.vcl để kiểm tra biên dịch theo bản cài. Thành công ở bước đó chỉ nói tệp được công cụ chấp nhận, không chứng minh dữ liệu phiên đã được bảo vệ. Bài không công bố kết quả chạy Varnish thật của khung này. Các tình huống hành vi phía dưới cần được thử trên lab có backend do anh em quản lý.

Varnish Cache proxy với bộ kiểm tra nội dung dùng chung

Bộ kiểm tra cần có tài nguyên công khai dễ nhận biết và tài nguyên theo phiên với dữ liệu thử khác nhau. Ghi kết quả mong đợi trước khi chạy để tránh chỉ nhìn hit rồi gọi thành công. Backend lab nên cung cấp dấu nhận biết phiên bản nội dung hoặc request ID không nhạy cảm. Không dùng dữ liệu khách hàng thật để thử nguy cơ phục vụ nhầm giữa hai người dùng.

Kiểm tra hit và miss với cùng tài nguyên

Gửi GET đầu tiên tới một tài nguyên công khai đã khai báo đúng header, rồi gửi lại trong TTL. Đối chiếu log để biết request thứ hai có được phục vụ từ cache hay không. Một response nhanh hơn chưa phải bằng chứng hit, vì backend có thể tự cache hoặc mạng đang khác. Nếu dùng header Age hoặc header chẩn đoán riêng, cần hiểu nó được tạo ở tầng nào và điều kiện xuất hiện.

Sau đó đổi nội dung ở backend trong lab và kiểm tra hành vi trước sau khi TTL hết. Kết quả mong đợi phải theo chính sách đã chọn, không mặc định mọi thay đổi xuất hiện ngay. Nếu ứng dụng cần cập nhật ngay, cần cơ chế vô hiệu hóa phù hợp thay vì chỉ hạ TTL trong mọi tình huống. Bài thử này giúp đội nội dung hiểu khoảng trễ có thể chấp nhận.

Kiểm tra hai phiên không được dùng chung

Tạo hai phiên thử với dữ liệu nhận biết khác nhau, lần lượt gọi cùng một tài nguyên riêng. Xác nhận mỗi phiên nhận đúng dữ liệu và không có hit chung ngoài ý muốn. Tiếp theo gọi request có Authorization và response có Set-Cookie để kiểm tra các nhánh loại. Không chỉ dùng một tài khoản quản trị vì nó có thể không phản ánh quyền và nội dung của người dùng bình thường.

Thử cả request không có cookie vào đường riêng, vì ứng dụng có thể trả trang đăng nhập hoặc một response khác. Một response 200 chứa trang đăng nhập không nên bị diễn giải thành dữ liệu công khai cần cache. Nội dung nghiệp vụ và trạng thái HTTP cần được đọc cùng nhau. Nếu route công khai thay đổi hành vi sau một bản phát hành, bộ kiểm tra phải giúp phát hiện điều đó trước khi cache được mở rộng.

Kiểm tra biến thể và lỗi backend

Nếu tài nguyên có biến thể theo ngôn ngữ hoặc định dạng, dùng hai request có kỳ vọng khác nhau để kiểm tra Vary cùng khóa cache. Nếu backend trả lỗi, xác nhận khung lab không lưu dùng chung response đó như nội dung thành công. Đừng thử lỗi bằng cách làm gián đoạn ứng dụng sản xuất. Có thể chuẩn bị endpoint hoặc chế độ lỗi riêng trong môi trường kiểm tra để giữ phạm vi tác động nhỏ.

Varnish Cache proxy khi cập nhật và vô hiệu hóa dữ liệu

TTL ngắn giảm thời gian dữ liệu cũ tồn tại nhưng không thay thế mọi yêu cầu làm mới. Một ứng dụng có thao tác xuất bản, thay giá hoặc thu hồi nội dung cần định nghĩa thời điểm bản cũ không còn được phục vụ. Cơ chế purge hoặc ban phải được chọn theo sản phẩm và thiết kế, có giới hạn người được gọi. Endpoint vô hiệu hóa mở rộng có thể bị lạm dụng để làm backend chịu tải liên tục.

Xác định ai có quyền làm mới

Người dùng Internet bình thường không nên có quyền xóa toàn bộ cache chỉ bằng một request đặc biệt. Nếu có tích hợp xuất bản, chỉ cho thành phần được xác thực gọi trong phạm vi cần thiết. Ghi tài nguyên, thời gian và lý do vô hiệu hóa để đội vận hành đối chiếu. Không đưa bí mật quản trị vào JavaScript phía client hoặc URL công khai dùng để trigger purge.

Làm mới đúng đối tượng

Một lần làm mới theo URL còn cần xét host và những biến thể liên quan. Nếu bỏ sót một biến thể, một nhóm người đọc có thể tiếp tục nhận bản cũ. Nếu làm mới quá rộng, hiệu quả cache giảm và backend có thể chịu đợt request dồn. Đội ứng dụng cần biết việc xuất bản tác động tới những đối tượng nào trước khi tự động hóa thao tác vô hiệu hóa.

Phân biệt nội dung cũ với khóa sai

Nếu người dùng thấy bản cũ trong TTL, có thể đó là hành vi đúng theo chính sách chưa phù hợp kỳ vọng. Nếu họ thấy nội dung của tenant khác, vấn đề nghiêm trọng hơn nằm ở phạm vi hoặc khóa. Purge có thể tạm che hiện tượng nhưng không sửa thiết kế. Giữ bằng chứng request, host, biến thể và nội dung thử để đội phụ trách xác định nhánh lỗi trước khi xóa dữ liệu liên quan.

Sau một thay đổi VCL, thử lại các tài nguyên đã từng được cache theo cấu hình cũ. Không nên giả định chỉ cần nạp cấu hình mới là mọi đối tượng cũ đã mang chính sách mới theo mong muốn. Hãy đọc hành vi của phiên bản và có kế hoạch xử lý trạng thái hiện hữu. Đây là phần khác với kiểm tra tệp VCL mới có biên dịch thành công hay không.

Varnish Cache proxy cần log và chỉ số có ý nghĩa

Tỷ lệ hit là một chỉ số hữu ích nhưng cần mẫu số và khoảng thời gian rõ ràng. Request bị pass do phiên không nhất thiết là thất bại của cache. Một dịch vụ có nhiều request riêng tư có thể có tỷ lệ hit thấp mà vẫn hoạt động đúng. Đừng tăng chỉ số bằng cách đưa dữ liệu nhạy cảm vào vùng dùng chung hoặc bỏ qua những nhóm request khó phân loại.

Kết hợp thống kê với một request mẫu

Tài liệu varnishstat mô tả công cụ xem thống kê của instance đang chạy. Dùng nó để nhìn xu hướng, sau đó chọn request mẫu trong log để hiểu nhánh xử lý. Khi counter được tính từ lúc tiến trình chạy, cần xem uptime và thời điểm chụp. Một counter tổng tăng không tự nói tỷ lệ của khoảng năm phút đang được điều tra.

Tài liệu varnishlog cung cấp công cụ xem giao dịch và các trường log tương ứng. Giữ phạm vi lọc theo bài thử, tránh thu toàn bộ cookie hoặc Authorization vào hồ sơ hỗ trợ. Người đọc cần biết request đi qua nhánh hit, miss hay pass và backend có được gọi không. Thông tin đó hữu ích hơn một ảnh tốc độ thiếu ngữ cảnh.

Đo giảm tải sau khi kiểm tra tính đúng

Nếu muốn đo tác động lên backend, dùng cùng tập request công khai và điều kiện trước sau có ghi nhận. Theo dõi số request tới backend, độ trễ và tài nguyên trong phạm vi thử. Không so một đợt đã nóng cache với một đợt chưa nóng rồi gọi đó là hiệu năng phổ quát. Ghi rõ quá trình làm ấm và những request bị pass theo chính sách.

Cache dùng chung chỉ có giá trị khi nội dung đúng người và đúng biến thể; tăng hit mà bỏ qua phạm vi dữ liệu có thể tạo một kết quả sai nhanh hơn.

Kiểm tra sức khỏe từng thành phần

Varnish còn hoạt động không có nghĩa backend đang phục vụ đúng, và backend khỏe không có nghĩa lớp cache còn nhận request. Kiểm tra sống của tiến trình nên khác kiểm tra một luồng ứng dụng thật. Nếu dùng probe hoặc endpoint sức khỏe, không để nó vô tình tạo phiên người dùng hoặc mang quyền quản trị không cần thiết. Mỗi kiểm tra cần một mục đích và tiêu chí rõ.

Varnish Cache proxy với lộ trình áp dụng có kiểm soát

Nên bắt đầu từ một nhóm tài nguyên công khai nhỏ và có chủ sở hữu rõ. Lưu VCL theo phiên bản, có cách quay lại và bộ thử cho dữ liệu theo phiên. Không mở cache toàn bộ website chỉ vì một trang tĩnh cho kết quả tốt. Mỗi loại route mới có thể thêm biến thể, cookie hoặc quyền khác, cần được duyệt theo hợp đồng ứng dụng của chính nó.

Nghiệm thu tính đúng trước hit

Ghi tiêu chí trước khi mở rộng

Một nhóm tài nguyên đủ điều kiện khi nội dung đúng với những request thử, trạng thái phiên không bị dùng chung và việc làm mới đáp ứng yêu cầu. Tiếp theo mới xem hiệu quả giảm request backend có đáng chi phí vận hành. Nếu không có dữ liệu thật, giữ đánh giá định tính và kế hoạch đo. Không tự tạo số phần trăm tăng tốc để làm tài liệu có vẻ thuyết phục hơn.

Nguồn được đối chiếu ngày 26/10/2026; một số đường tài liệu cũ chuyển sang website tài liệu mới nên cần kiểm tra lại theo phiên bản cài. Khung VCL là ví dụ để biên dịch và thử trong lab, chưa phải cấu hình đã nghiệm thu cho WordPress hoặc một ứng dụng thương mại. Những tích hợp như TLS, load balancer, nhiều backend và quản lý bí mật cần thiết kế riêng nếu nằm trong phạm vi triển khai.

Thử yêu cầu làm mới từ client riêng với hết TTL

Một client có thể gửi chỉ thị Cache-Control để yêu cầu cách dùng bản lưu theo ngữ cảnh HTTP. Khung lab chọn pass khi request có header này, nhằm giữ bài thử hẹp và tránh diễn giải nhầm hành vi làm mới của browser. Đây là chính sách của ví dụ, không phải khuyến nghị loại mọi request như vậy trong mọi hệ thống. Trước khi tối ưu thêm, kiểm tra từng chỉ thị và những yêu cầu revalidation mà ứng dụng cần hỗ trợ.

Khi browser bấm tải lại, request có thể khác lần truy cập ban đầu về header hoặc điều kiện. Vì vậy, không nên dùng thao tác refresh không ghi nhận header làm phép thử hit lặp tương đương. Hãy giữ một client lab có request cố định để kiểm tra cache cơ bản, sau đó thử riêng hành vi trình duyệt. Cách tách này giúp phân biệt một miss đúng chính sách với lỗi cấu hình khiến cache không hoạt động.

Xác nhận response sau cập nhật không trộn phiên bản

Một trang HTML công khai có thể trỏ tới nhiều tài nguyên tĩnh với vòng đời khác nhau. Nếu chỉ vô hiệu hóa HTML nhưng đổi nội dung tệp ở cùng URL theo cách không tương thích, client có thể gặp tổ hợp phiên bản chưa được kiểm tra. Đội ứng dụng nên có quy tắc đặt phiên bản tài nguyên và thử cả luồng người dùng đang mở trang cũ. Cache không tự giải quyết tính tương thích giữa các bản phát hành chỉ bằng một TTL chung.

Giữ vai trò của từng lớp rõ ràng

Bài reverse proxy tổng quan giúp hiểu vị trí trung gian, còn bài này tập trung vào hợp đồng cache công khai và tính đúng theo phiên. Nếu mục tiêu chỉ là đổi IP của công cụ, hãy chọn forward proxy phù hợp thay vì thêm Varnish vào kiến trúc. Nếu mục tiêu là giảm xử lý lặp ở backend, dùng cache có chính sách và kiểm chứng. Sự phân biệt này giúp tránh chọn công nghệ chỉ từ chữ proxy trong tên gọi.

Varnish Cache proxy nên bắt đầu từ nội dung công khai, TTL có giới hạn và bộ kiểm tra không dùng chung dữ liệu phiên. Anh em hãy nghiệm thu tính đúng trước khi tối ưu tỷ lệ hit. Trao đổi cùng Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để phân biệt nhu cầu IP đường ra với Varnish Cache proxy.