Đến nội dung chính
Infra Notes
DOCS / UTF-8
Runbook // Quy trình vận hànhcloudflare

Cloudflare — Vận hành và xử lý sự cố

DOC PATH runbooks/cloudflare/operations

Doc Type
Runbook
Technology
cloudflare
Status
Active
Tags
cloudflareOperationstroubleshootingapi

Khoanh vùng sự cố Cloudflare từ DNS tới application, thu thập bằng chứng trước khi sửa và xác minh kết quả sau mỗi thay đổi. Runbook cũng cung cấp baseline production và các nguyên tắc dùng API an toàn cho System Administrator.

Áp dụng cho website, HTTP API và application sử dụng Cloudflare DNS/proxy, WAF, cache, Tunnel, Access hoặc Load Balancing. Chọn nhánh phù hợp với kiến trúc thực tế; một hệ thống không nhất thiết có tất cả các thành phần này. Khái niệm và luồng traffic nằm ở DNS, TLS và kiến trúc kết nối; WAF, cache và thứ tự Rules nằm ở Security, Cache và Rules.

  • Có inventory hostname, zone/account, origin và các lớp LB/proxy/firewall liên quan.
  • Có quyền đọc DNS, Analytics, Security Events và log của các thành phần cần kiểm tra.
  • Biết hostname đang Proxied hay DNS Only và có dùng Tunnel/Access/LB hay không.
  • Ghi nhận thay đổi gần nhất, thời điểm bắt đầu lỗi, phạm vi user và endpoint bị ảnh hưởng.
  • Máy kiểm tra đã có dig, curl, openssl; traceroute và mtr dùng khi cần khoanh vùng mạng.
  • Các tên miền và IP trong ví dụ là giá trị đại diện. Thay app.example.com, ns1.example.net và 203.0.113.10 bằng giá trị thuộc phạm vi được phép kiểm tra.

Các lệnh bên dưới chỉ truy vấn DNS, gửi request HTTP, thử TLS handshake hoặc gửi probe mạng; chúng không sửa cấu hình Cloudflare hay Linux. Tuy vậy, request vẫn tạo traffic, có thể xuất hiện trong log, làm nóng cache hoặc kích hoạt WAF/Rate Limit. Chọn URL GET/HEAD không gây thay đổi dữ liệu, chạy số lượng nhỏ và tránh endpoint tốn tài nguyên.

curl -v có thể hiển thị header, cookie và dữ liệu cần giữ nội bộ. Khi lưu kết quả vào ticket, che credential và thông tin riêng của hệ thống. Kiểm tra origin trực tiếp chỉ thực hiện từ vị trí đã được phép; không mở firewall để chạy mẫu lệnh.

Đây là thứ tự khoanh vùng, không phải thứ tự thực thi mọi phase nội bộ của Cloudflare:

Client → DNS → Cloudflare Edge/TLS → Rules/WAF/Cache
→ LB/Tunnel → Origin Firewall → Nginx/App → DB
  1. Ghi bằng chứng: URL/path, timestamp kèm timezone, HTTP/error code và Ray ID; xác định lỗi liên tục hay gián đoạn.
  2. Kiểm tra DNS: câu trả lời đúng không, delegation có đúng không và hostname đang Proxied hay DNS Only?
  3. Kiểm tra public URL: dùng curl, ghi status, cf-ray, cf-cache-status, Age và Cache-Control nếu có.
  4. Đối chiếu tại Cloudflare: Security Events cho request bị chặn, Trace cho rule match/order và Analytics cho xu hướng lỗi/latency.
  5. Kiểm tra LB/Tunnel nếu có: pool/endpoint, monitor và connector; phân biệt connectivity với application health.
  6. Kiểm tra origin: firewall, listener, đường mạng và TLS/certificate theo đúng hostname/SNI.
  7. Kiểm tra application/DB: latency, slow endpoint/query, dependency và log cùng khoảng thời gian.
  8. Sửa và verify từng nhóm nguyên nhân: tái hiện cùng điều kiện, so sánh trước/sau rồi ghi kết quả vào hồ sơ incident.

Cloudflare khuyến nghị cung cấp mã lỗi, thời gian kèm timezone và URL; log của LB, proxy, cache và firewall giữa Cloudflare với origin cũng cần được xem. Xem hướng dẫn Cloudflare 5xx errors.

CF-Ray giúp nối bằng chứng từ client, Security Events/Logs và origin logs. Thu thập cùng URL, timestamp/timezone, status và thành phần phát sinh lỗi. Origin nên ghi header này để lần theo request từ Cloudflare.

Ray ID không được bảo đảm duy nhất cho mọi request. Security Events có thể dùng dữ liệu sampled; không thấy event trong một lần tìm kiếm chưa đủ để kết luận request không qua Cloudflare. Thu hẹp khoảng thời gian và đối chiếu thêm origin logs. Xem Cloudflare Ray ID.

Bảng này dành cho HTTP traffic qua Cloudflare tới origin. Mã lỗi xác định hướng kiểm tra; cần log và phép thử để kết luận nguyên nhân.

Mã Ý nghĩa vận hành Kiểm tra trước
520 Origin trả phản hồi rỗng, bất thường hoặc Cloudflare không xử lý được Origin/app logs, headers, protocol và các proxy trung gian
521 Origin từ chối kết nối từ Cloudflare Web server có listen không, firewall REJECT, Cloudflare IP bị chặn/rate limit
522 Cloudflare bị timeout khi liên lạc với origin Firewall DROP, packet loss, origin quá tải, route và origin IP
523 Cloudflare không tới được origin Origin IP trong DNS, routing và đường mạng giữa Cloudflare với origin
524 Đã kết nối origin nhưng phản hồi HTTP hoặc ghi dữ liệu vượt timeout Application/DB latency, slow endpoint/query, tài nguyên origin và loại timeout
525 TLS handshake Cloudflare–origin thất bại Cổng TLS/listener, protocol/cipher, SNI và TLS error logs
526 Certificate origin không đạt strict validation Expiry, SAN/hostname, CA tin cậy và đầy đủ certificate chain
Triệu chứng Hướng kiểm tra
NXDOMAIN hoặc sai IP DNS record, delegation, DNSSEC và cache resolver
403 Security Events/WAF/Access trước; đối chiếu origin logs vì origin cũng có thể trả 403
522 Connectivity Cloudflare → origin; listener/firewall/network trước khi sửa application
524 chỉ tại một path Endpoint application/DB và thời gian xử lý của path đó
525 hoặc 526 TLS/certificate phía origin; tách handshake khỏi validation
Nội dung cũ CF-Cache-Status, Age, Cache-Control, cache key; sau đó kiểm tra browser cache
Tunnel Healthy nhưng 502 Tách đoạn Cloudflare ↔ cloudflared khỏi đoạn cloudflared ↔ local app
LB failover sai Monitor response, Host header/SNI, firewall và góc nhìn health của monitor

Chạy trên máy client hoặc máy kiểm tra Linux đã được phép truy vấn. Các lệnh không đổi record và không xóa cache:

Terminal window
dig app.example.com
dig @1.1.1.1 app.example.com
dig @8.8.8.8 app.example.com
dig @ns1.example.net app.example.com
  • Lệnh đầu dùng resolver của máy; hai lệnh sau so sánh resolver công khai độc lập.
  • Lệnh cuối truy vấn authoritative nameserver thực tế của zone. ns1.example.net chỉ là ví dụ, không phải nameserver được gán cho zone của bạn.
  • Đọc status, ANSWER, IP/target và TTL. Nếu authoritative đã đúng nhưng recursive resolver còn câu trả lời cũ, xem TTL/cache trước khi sửa record lần nữa.
  • Với hostname Proxied, IP trả về thuộc Cloudflare thay vì origin. DNS Only đi tới origin/target; web request đó không nhận các chức năng HTTP proxy như WAF/cache.
Terminal window
curl -v --connect-timeout 5 --max-time 15 https://app.example.com
curl -I --connect-timeout 5 --max-time 15 https://app.example.com/logo.png

Lệnh đầu gửi GET và hiển thị quá trình kết nối cùng header; dùng để xem DNS/TLS, status và redirect. Lệnh thứ hai gửi HEAD tới asset, ưu tiên đọc CF-Cache-Status, Age, Cache-Control và cf-ray. Hai giới hạn timeout bảo đảm phép thử kết thúc; chúng là timeout của curl, không phải timeout phía Cloudflare.

HIT cho thấy object được trả từ cache; MISS, DYNAMIC hoặc BYPASS cần được đọc cùng cache eligibility, response headers và rule đang áp dụng. Proxied không có nghĩa response luôn được cache. Application có thể xử lý HEAD khác GET; kiểm tra lại bằng GET an toàn khi cần.

Chỉ dùng từ mạng/máy đã có quyền tới origin. Các phép thử này bỏ qua đường HTTP proxy Cloudflare, nên không chứng minh WAF/Access/Rules hoạt động đúng:

Terminal window
curl -v --connect-timeout 5 --max-time 15 \
--resolve app.example.com:443:203.0.113.10 https://app.example.com
openssl s_client -connect 203.0.113.10:443 \
-servername app.example.com -showcerts </dev/null

curl --resolve chỉ ép IP cho hostname/port trong lần chạy này, giữ hostname trong URL để kiểm tra Host/SNI; không sửa DNS hệ thống. So sánh status, latency và certificate với public URL để xác định lỗi ở edge hay origin.

openssl s_client tạo TLS handshake tới origin, gửi SNI và hiển thị certificate chain. Đọc cert được chọn, SAN, thời hạn, issuer, các intermediate và thông báo handshake/verification. Việc handshake thành công không tự chứng minh certificate đủ điều kiện Full (strict); trình kiểm tra phải dùng đúng hostname và trust store.

Origin CA được Cloudflare tin cậy nhưng máy client thông thường có thể không tin CA này. Lỗi trust khi truy cập origin trực tiếp cần được giải thích theo loại certificate; không thêm -k để biến kiểm tra certificate thành kết quả thành công. Xem Cloudflare Origin CA.

Terminal window
traceroute 203.0.113.10
mtr -r -w -c 10 203.0.113.10

traceroute quan sát các hop; mtr tổng hợp độ trễ/loss qua mười vòng probe rồi thoát. Thay IP bằng đích thuộc phạm vi cần kiểm tra. Với 522/523, phép thử từ origin tới Cloudflare IP từng kết nối trong origin logs thường cung cấp góc nhìn hữu ích hơn phép thử từ laptop tới origin. Xem hướng dẫn lỗi 522.

Router có thể giảm ưu tiên hoặc chặn probe; một hop không trả lời chưa đủ để kết luận ứng dụng bị packet loss. Đối chiếu loss tới đích và phép thử TCP/HTTP, đồng thời lưu thời gian cùng vị trí máy thực hiện.

Credential Mục đích Cách quản lý
API Token Quản trị Cloudflare control plane qua API Least privilege, đúng account/zone và resource cần thao tác
Tunnel Token Cho cloudflared kết nối tunnel Lưu như secret của connector; không dùng thay API Token
Access Service Token Machine truy cập application được Access bảo vệ Client ID + Client Secret; gắn policy phù hợp, không dùng thay Tunnel/API Token

Ưu tiên API Token thay Global API Key cho automation mới. Zone ID và Account ID là identifier được các endpoint sử dụng, không phải credential. Lấy secret qua secret manager, CI secret hoặc Vault; không hardcode trong script/Git và không ghi vào shell history hay log. Xem Create API token.

Mẫu header và base URL, chưa phải một thao tác thay đổi:

Authorization: Bearer <API_TOKEN>
https://api.cloudflare.com/client/v4

Đối chiếu method, permissions, payload và response schema của endpoint trước khi viết automation. Cách xác thực và pagination được mô tả trong Make API calls.

  1. Read: đọc cấu hình/resource hiện tại bằng endpoint đúng account/zone, lưu trạng thái trước thay đổi ở nơi nội bộ.
  2. Compare: so sánh với cấu hình mong muốn, chỉ ra trường thay đổi và ảnh hưởng tới traffic; bỏ qua khi đã đúng.
  3. Change: thực hiện thay đổi hẹp theo phạm vi đã phê duyệt; tránh POST/PATCH mù quáng và ghi định danh resource để kiểm tra lại.
  4. Verify: đọc lại qua API, kiểm tra hành vi thật bằng DNS/HTTP/application và ghi kết quả; response API thành công chưa đủ xác nhận dịch vụ hoạt động đúng.

API list có thể phân trang. Xử lý pagination theo schema của endpoint để không coi trang đầu là toàn bộ inventory. Khi gặp 429, đọc retry-after/rate-limit headers, chờ theo hướng dẫn và dùng retry có giới hạn; không lặp dồn dập. Xem Cloudflare API rate limits.

Terraform/IaC phù hợp cho cấu hình cần duy trì bằng version control. Xác định resource nào do IaC quản lý; vừa sửa tay vừa để Terraform quản lý cùng resource dễ gây drift hoặc ghi đè thay đổi khi apply tiếp theo.

  • Tái hiện URL/path với cùng hostname, method và điều kiện Access/authentication liên quan.
  • DNS/delegation đúng, TLS được kiểm tra theo loại certificate và public URL phản hồi như mong đợi.
  • WAF/Access còn thực thi policy; exception chỉ áp dụng cho endpoint/điều kiện cần thiết.
  • Cache đúng với loại nội dung; session/account/cart không bị trả từ cache dùng chung ngoài thiết kế.
  • Nếu có LB/Tunnel, kiểm tra application phía sau và monitor/connector; trạng thái Healthy riêng lẻ chưa đủ.
  • Theo dõi error rate, latency và log trong khoảng thời gian phù hợp; lưu kết quả trước/sau cùng Ray ID nếu có.

Dừng các thay đổi tiếp theo, giữ bằng chứng và quay lại đúng giá trị trước đó của phần vừa sửa theo kế hoạch thay đổi. Thực hiện rollback từng phần rồi kiểm tra lại DNS/HTTP/application; không thay nhiều nhóm setting cùng lúc.

Rollback exception/rule hoặc cấu hình routing phải hẹp theo resource vừa thay. Nếu lỗi là certificate, sửa certificate/chain/hostname thay vì coi việc hạ Full (strict) xuống Full là kết thúc incident. Nếu lỗi là false positive, điều chỉnh rule/exception cụ thể thay vì tắt toàn bộ WAF. Nếu là 524, ưu tiên application/DB và loại timeout thay vì purge cache hoặc chỉnh DNS thiếu bằng chứng.

Đối chiếu gói dịch vụ và thiết kế thực tế trước khi áp dụng. Checklist này là chuẩn kiểm tra; thay đổi production cần kế hoạch, người chịu trách nhiệm và bước xác minh tương ứng.

  1. Web hostname A/AAAA/CNAME dùng Proxied khi cần HTTP proxy; mail/verification dùng DNS Only đúng mục đích.
  2. SSL/TLS dùng Full (strict); certificate origin còn hạn, đúng hostname và chain.
  3. Origin không mở public trực tiếp khi không cần. Nếu public, giới hạn đường vào từ Cloudflare và bảo vệ management path riêng.
  4. Khôi phục/log IP visitor bằng CF-Connecting-IP sau khi đã giới hạn nguồn tin cậy và khóa đường bypass origin.
  5. Dùng Managed WAF theo khả năng của gói; Custom Rules phục vụ yêu cầu cụ thể, exception nhỏ nhất có thể.
  6. Rate Limit login/API nhạy cảm dựa trên traffic thực tế; tránh threshold quá thấp gây ảnh hưởng user chung IP NAT/CGNAT.
  7. Cache static assets phù hợp; tránh cache mù quáng nội dung có session/account/cart.
  8. Dùng versioned/hash asset để đặt TTL dài và giảm nhu cầu purge.
  9. Private/internal app cân nhắc Tunnel + Access để giảm inbound public và kiểm soát người truy cập.
  10. HA dùng health check phản ánh application, kiểm thử failover/failback trong phạm vi cho phép; DB/session/storage có HA tương ứng.
  11. Log CF-Ray ở origin; duy trì runbook cho 52x, WAF false positive, Tunnel và LB incident.
Sai lầm Cách xử lý phù hợp
Tắt toàn bộ WAF vì một false positive Xác định request/rule ID và tạo exception hẹp
Chuyển Full (strict) xuống Full rồi bỏ quên certificate lỗi Sửa certificate và xác minh lại strict validation
Cache Everything cho site có login/session Phân loại nội dung public/private và kiểm cache key/eligibility
Thấy 524 rồi purge cache hoặc chỉnh DNS Kiểm app/DB latency và loại timeout trước
Tunnel Healthy nên kết luận application healthy Kiểm riêng cloudflared → local app
DNS-only web nhưng kỳ vọng WAF/CDN của proxy Đối chiếu đường traffic và Proxy Status
Origin public không giới hạn direct access Khóa bypass bằng biện pháp origin security phù hợp
Active-Active web nhưng bỏ qua DB/session/data consistency Thiết kế HA và đồng bộ state ở lớp application/data
Token All Zones/All Permissions cho một zone DNS Giới hạn quyền và resource theo tác vụ