Reference // Tra cứu kỹ thuậtcloudflare

CLOUDFLARE — DNS, TLS và kiến trúc kết nối

DOC PATH reference/cloudflare/theory

Doc Type: Reference
Technology: cloudflare
Status: Active
Tags: cloudflarednstlstunnelaccessHA

Cloudflare có thể cung cấp Authoritative DNS và reverse proxy đứng trước origin. Trang này giải thích đường đi của request, ranh giới bảo vệ, TLS và các thành phần kết nối để tra cứu khi thiết kế hoặc vận hành website, HTTP API và ứng dụng nội bộ.

Tra cứu nhanh

Chủ đề	Điểm cần nhớ
DNS Only / Proxied	DNS Only đưa client tới origin; Proxied đưa HTTP(S) qua Cloudflare Edge.
TLS	Với request HTTPS proxied có hai kết nối riêng: client ↔ Cloudflare và Cloudflare ↔ origin. Ưu tiên Full (strict) cho origin HTTPS.
Origin Security	Orange Cloud không tự đóng đường truy cập trực tiếp tới origin. Cần firewall, AOP hoặc Tunnel phù hợp.
Security	WAF kiểm tra request HTTP; Rate Limiting đếm request theo key/thời gian; DDoS Protection giảm thiểu tấn công.
Cache	Proxied không đồng nghĩa response được cache. Kiểm tra `CF-Cache-Status`, `Cache-Control` và Cache Rules.
Tunnel / Access	Tunnel cung cấp connectivity; Access kiểm soát danh tính và quyền truy cập. Published application qua Tunnel vẫn có thể public.
HA	Load Balancer chọn pool/endpoint theo health và steering. HA của database, session và storage phải được thiết kế riêng.
Incident	Ghi URL, timestamp/timezone, error code và Ray ID; khoanh vùng layer trước khi thay đổi.

Traffic và Reverse Proxy

DNS trả lời địa chỉ cần kết nối. HTTP/HTTPS mới là luồng truyền nội dung. Cùng một nhà cung cấp DNS không có nghĩa mọi traffic đều qua proxy.

DNS Only
DNS:   Client → Recursive Resolver → Cloudflare Authoritative DNS → Origin IP
HTTPS: Client ───────────────────────────────────────────────────→ Origin

Proxied (Orange Cloud)
DNS:   Client → Recursive Resolver → Cloudflare Authoritative DNS → Cloudflare IP
HTTPS: Client → Cloudflare Edge → Origin

Thành phần	Ý nghĩa vận hành
Reverse Proxy	Nhận request từ client, sau đó tạo kết nối riêng tới backend khi cần.
Anycast	Nhiều điểm hiện diện (PoP) quảng bá cùng prefix; routing đưa client tới một Edge phù hợp.
Origin	Server, load balancer hoặc backend thực sự cung cấp nội dung.
`CF-Connecting-IP`	Header truyền IP visitor tới origin trong luồng proxied thông thường.
`CF-Ray`	Mã giúp đối chiếu request trong Cloudflare logs, Security Events và origin logs.

Cloudflare Edge rộng hơn CDN cache. Request có thể dùng TLS, WAF hoặc Rules nhưng vẫn phải tới origin để lấy nội dung. Các trường hợp cache và Rules được mô tả trong Security, Cache và Rules.

DNS

Luồng phân giải và record types

Application → Stub Resolver → Recursive Resolver → Root → TLD → Authoritative DNS

Resolver thường dùng cache nên một truy vấn không nhất thiết đi qua toàn bộ chuỗi. 1.1.1.1 là recursive resolver; nameserver được cấp cho zone là authoritative DNS. Hai vai trò này khác nhau.

Record	Công dụng	Lưu ý
A	Hostname → IPv4.	Có thể Proxied cho dịch vụ HTTP(S) tương thích.
AAAA	Hostname → IPv6.	Tương tự A; kiểm tra cả đường IPv6 khi điều tra lỗi.
CNAME	Hostname → hostname khác.	Không phải HTTP redirect; có thể Proxied cho web.
MX	Domain → mail server.	Record không Proxied; A/AAAA của mail host nên DNS Only.
TXT	SPF, DKIM, DMARC và verification.	Metadata; không Proxied.
NS	Delegation nameserver.	Dùng để ủy quyền zone/subdomain.
CAA	Giới hạn CA được phép cấp certificate.	Kiểm tra khi certificate issuance gặp lỗi.

Proxied và DNS Only

Hạng mục	Proxied — Orange Cloud	DNS Only — Gray Cloud
DNS trả về	Cloudflare Anycast IP.	Địa chỉ origin/target được phân giải.
HTTP(S)	Qua Cloudflare Edge.	Đi tới origin/target trực tiếp.
WAF, HTTP DDoS, Cache, Rules	Áp dụng cho traffic đi qua proxy, tùy cấu hình.	Các tính năng của HTTP proxy không áp dụng cho đường trực tiếp.
Origin IP	Không xuất hiện trong câu trả lời proxied thông thường.	Có thể thấy trong DNS.
Trường hợp sử dụng	Website, web app và HTTP API trên giao thức/cổng được hỗ trợ.	Mail, verification và các dịch vụ không tương thích HTTP proxy.

Chỉ A/AAAA/CNAME có khả năng bật proxy. CNAME dùng xác minh quyền sở hữu cũng thường cần DNS Only. Kiểm tra Proxy status và Proxying limitations khi chọn trạng thái record.

TTL và DNS propagation

TTL cho biết câu trả lời DNS được cache trong bao lâu, không phải tuổi thọ của record. Khi thay đổi DNS, các resolver có thể tiếp tục trả dữ liệu cũ cho tới khi cache hết hạn.

Hạ TTL trước migration đủ sớm; TTL mới không rút ngắn thời gian của câu trả lời đã được cache.
Proxied records dùng TTL Auto; đối chiếu Time to Live thay vì áp dụng TTL của DNS Only.
ipconfig /flushdns chỉ làm mới cache DNS trên Windows đang chạy lệnh; không làm mới cache của ISP hay recursive resolver.
DNS TTL, Edge Cache TTL và Browser Cache TTL quản lý ba lớp khác nhau. Xem Ba loại TTL.

Bộ truy vấn sau chỉ đọc DNS, không sửa zone. Mỗi truy vấn tạo lưu lượng DNS và có thể được resolver ghi log. Thay hostname mẫu bằng hostname cần kiểm tra; gán biến nameserver từ thông tin authoritative thực tế.

dig app.example.com
dig @1.1.1.1 app.example.com
dig @8.8.8.8 app.example.com

AUTHORITATIVE_NS='ns.example.net'
dig @"$AUTHORITATIVE_NS" app.example.com

Lệnh đầu dùng resolver của máy; hai lệnh tiếp theo đối chiếu recursive resolver công cộng; lệnh cuối hỏi authoritative nameserver đã xác minh. So sánh answer, TTL và trạng thái NOERROR, NXDOMAIN hoặc SERVFAIL để phân biệt record thiếu với cache/delegation/DNSSEC lỗi.

Onboarding và đổi nameserver

Đổi authoritative provider có thể ảnh hưởng web, API, mail và mọi subdomain. Trước thay đổi, lưu bản export DNS, nameserver hiện tại và trạng thái DNSSEC/DS để có kế hoạch khôi phục phù hợp.

Kiểm kê A/AAAA/CNAME, MX, SPF/DKIM/DMARC và record verification.
Thêm zone, kiểm tra kết quả Quick Scan hoặc import; scan không bảo đảm phát hiện đủ record.
Chọn Proxy Status theo chức năng từng hostname.
Đối chiếu DNSSEC và DS ở parent/registrar với kế hoạch migration.
Đổi NS tại registrar hoặc parent sau khi kiểm tra dữ liệu zone mới.
Khi zone Active, kiểm tra delegation, DNS và chức năng thực tế của web/API/mail cùng các subdomain quan trọng.

DS còn trỏ tới khóa của provider cũ có thể làm validating resolver trả SERVFAIL. Thứ tự cập nhật DNSSEC/DS phải theo mô hình migration đã chọn. Nếu giữ DNSSEC liên tục bằng multi-signer, đối chiếu điều kiện của DNSSEC active migration; các mô hình khác cần theo hướng dẫn DNSSEC của provider và registrar.

SSL/TLS

Hai kết nối độc lập

Client ↔ Cloudflare Edge        Cloudflare ↔ Origin
       TLS #1                         TLS #2

Sơ đồ áp dụng cho client HTTPS và origin HTTPS. Edge certificate bảo vệ đoạn đầu; origin certificate bảo vệ đoạn sau. HTTPS trên trình duyệt chưa chứng minh Cloudflare đang xác minh certificate của origin.

Encryption modes

Mode	Client HTTPS ↔ Cloudflare	Cloudflare ↔ origin cho request HTTPS	Lưu ý
Flexible	TLS.	HTTP plaintext.	Có thể tạo redirect loop khi origin ép HTTPS; không phù hợp baseline bảo vệ end-to-end.
Full	TLS.	TLS nhưng không xác minh tính hợp lệ của origin certificate.	Không bảo đảm chống giả mạo origin; cần kế hoạch chuyển sang strict.
Full (strict)	TLS.	TLS và xác minh origin certificate.	Ưu tiên cho origin HTTPS đã có certificate hợp lệ.

Bảng giả định request đầu vào dùng HTTPS. Với Full, scheme của visitor ảnh hưởng kết nối tới origin; chọn mode không tự chuyển mọi HTTP của client thành HTTPS. Cần chính sách ép HTTPS phù hợp.

Full (strict) yêu cầu certificate còn hạn, CN/SAN khớp requested hoặc target hostname và được CA công cộng hoặc Cloudflare Origin CA tin cậy. Origin cũng phải có HTTPS listener và certificate chain phù hợp.

Edge certificate và Origin certificate

Certificate	Vị trí	Bên xác minh	Phạm vi
Edge / Universal SSL	Cloudflare Edge.	Browser/client.	Bảo vệ client ↔ Cloudflare.
Public CA, ví dụ Let’s Encrypt	Origin.	Cloudflare; browser có thể xác minh khi đi trực tiếp.	Dùng được cho Full (strict) khi đáp ứng hostname/expiry/chain.
Cloudflare Origin CA	Origin.	Cloudflare.	Dùng cho Cloudflare ↔ origin; browser trực tiếp thường không tin cậy.

Tắt proxy hoặc pause Cloudflare với origin chỉ dùng Origin CA có thể khiến client gặp lỗi trust certificate. Xem Origin CA trước khi thay đổi đường đi traffic.

Chain, SNI và kiểm tra origin

Certificate chain thường gồm leaf và intermediate; root nằm trong trust store của bên xác minh. SNI trong TLS ClientHello cho phép server dùng chung IP chọn certificate/vhost theo hostname.

525: TLS handshake Cloudflare ↔ origin thất bại.
526: origin certificate không vượt qua strict validation.

Các lệnh dưới đây mở kết nối TLS/HTTPS trực tiếp tới IP minh họa 203.0.113.10. Chỉ chạy với origin được phép kiểm tra, từ đường quản trị đã có quyền truy cập; request có thể vào access log. Firewall/AOP chặn truy cập trực tiếp có thể là hành vi đúng, không phải lỗi.

openssl s_client -connect 203.0.113.10:443 \
  -servername app.example.com -showcerts </dev/null

curl -v --connect-timeout 5 --max-time 20 \
  --resolve app.example.com:443:203.0.113.10 https://app.example.com/

openssl s_client hiển thị handshake và certificate được origin trả theo SNI. curl --resolve giữ hostname, Host header và SNI trong URL nhưng kết nối IP chỉ định; giúp đối chiếu origin với public path. Không thêm -k để bỏ qua lỗi certificate. Nếu origin dùng Origin CA, trust store của máy kiểm tra có thể chưa tin CA đó; kết quả trực tiếp không thay thế kiểm tra Full (strict) từ Cloudflare.

Bảo vệ Origin

Origin public mở port web có thể nhận request bỏ qua Cloudflare khi IP bị biết. Vì vậy cần kiểm soát network, xác thực hoặc đường kết nối phù hợp với kiến trúc.

Biện pháp	Vai trò	Điều kiện vận hành
Firewall allow Cloudflare IPs	Hạn chế inbound web tới origin public/LB.	Theo dõi dải IP chính thức, xử lý IPv4/IPv6 và giữ đường quản trị riêng.
Authenticated Origin Pulls (AOP)	Origin xác minh client certificate của kết nối Cloudflare.	Origin phải thực sự enforce client-certificate validation; kết hợp Full (strict).
Cloudflare Tunnel	Connector tạo kết nối outbound tới Cloudflare.	Giảm nhu cầu public inbound web; vẫn phải bảo vệ app, connector và các đường truy cập khác.

Firewall thay đổi sai có thể làm mất traffic hợp lệ hoặc quyền quản trị. AOP enforce sai có thể làm mọi origin pull thất bại. Đối chiếu Cloudflare IP ranges và AOP trước khi lập thay đổi.

AOP và Origin CA

Full (strict)/Origin CA xác minh origin về phía Cloudflare. AOP xác minh client về phía origin. Hai hướng này bổ sung nhau trong mô hình origin HTTPS public.

Global AOP dùng certificate chung cho nhiều account: nó chứng minh kết nối từ mạng Cloudflare, không chứng minh thuộc riêng zone của bạn. Nếu cần ràng buộc chặt hơn, xem zone-level AOP hoặc per-hostname với certificate riêng. Xem phạm vi certificate chung trong Global AOP.

IP visitor và trusted proxy

Trong luồng proxied thông thường, TCP source ở origin là Cloudflare IP; IP visitor được chuyển qua CF-Connecting-IP. Chỉ trust header từ proxy/connector được xác minh và cấu hình trusted proxy đúng hop.

Cloudflare Tunnel

cloudflared là connector chạy trong mạng có thể tới dịch vụ cần publish. Nó thiết lập kết nối outbound tới Cloudflare và chuyển request nhận được tới local service.

Kết nối do connector khởi tạo:
cloudflared ── outbound ──→ Cloudflare

Luồng request qua published application:
User → Cloudflare → kết nối Tunnel → cloudflared → local service

Origin không bắt buộc có public IP hoặc mở inbound web port cho đường Tunnel. Ví dụ published hostname app.example.com có thể map tới http://<service-host>:8080; hostname và giao thức local service phải khớp cấu hình thực tế. HTTP trên đoạn connector ↔ app vẫn cần được đánh giá theo ranh giới mạng.

Connectivity và HA

Cho phép egress cần thiết; Tunnel dùng TCP 7844 cho HTTP/2 hoặc UDP 7844 cho QUIC. Các nhu cầu như DNS, quản trị và update phải đối chiếu riêng.
Một connector host vẫn là failure domain. Dùng replica trên host/đường mạng phù hợp để tránh phụ thuộc duy nhất vào một máy.
Replica kết nối cùng tunnel không tự tạo HA cho app hoặc database. Khi cần health-aware steering/alert, xem Load Balancing.
Tunnel Healthy phản ánh kết nối connector ↔ Cloudflare; connector vẫn có thể không tới được local service.

Đối chiếu Tunnel configuration cho egress và replicas, cùng Tunnel troubleshooting khi tunnel có kết nối nhưng request vẫn lỗi.

Zero Trust và Access

Access cung cấp authentication và authorization trước ứng dụng. Tunnel chỉ là một lựa chọn connectivity tới origin; hai lớp này cần được thiết kế cùng nhau khi bảo vệ private app.

User → Access → IdP authentication → Access policy → Tunnel/Origin → App

Khái niệm	Trách nhiệm
Authentication	Xác minh danh tính qua IdP như Entra ID, Okta hoặc Google; kết hợp MFA phù hợp.
Authorization	Xác định danh tính/request có được vào ứng dụng theo policy hay không.
Access Application	Phạm vi hostname/path hoặc tài nguyên được Access bảo vệ.
Service Auth	Kiểm soát machine-to-machine bằng service token/mTLS theo thiết kế.

Policy logic và action

Rule type	Logic
Include	OR: thỏa ít nhất một điều kiện Include.
Require	AND: thỏa tất cả điều kiện Require.
Exclude	Loại khỏi policy những đối tượng match điều kiện Exclude.

Action	Hành vi
Allow	Cho đối tượng đã xác thực và match policy truy cập.
Block	Chặn đối tượng match policy.
Bypass	Bỏ qua Access enforcement cho traffic match; giới hạn cho endpoint thật sự cần public.
Service Auth	Cho machine hợp lệ truy cập theo policy mà không cần browser login tương tác.

Access là deny by default cho application được bảo vệ; thông thường user không match Allow sẽ bị từ chối. Cần kiểm tra cả Service Auth và Bypass: chúng được đánh giá trước nhóm Block/Allow. Không thêm Block Everyone chỉ để chặn phần còn lại vì thứ tự có thể chặn user hợp lệ. Xem Access policies khi kết hợp nhiều action.

Access Service Token gồm Client ID và Client Secret, phải lưu trong secret manager. Nó khác API Token quản trị control plane và Tunnel Token của connector; xem API và automation.

Load Balancing và High Availability

Load Balancer → Pool → Endpoint
                 ↑       ↑
            Monitor → health checks

Thành phần	Vai trò
Endpoint	Server/service cuối nhận traffic.
Pool	Nhóm endpoint, thường đại diện một site, region hoặc cụm.
Monitor	Thực hiện health check HTTP/HTTPS/TCP theo cấu hình.
Load Balancer	Chọn pool/endpoint theo health và traffic steering.

Các đối tượng này được định nghĩa trong Load Balancing components. Tính năng steering, health monitor và session affinity phụ thuộc mô hình và gói dịch vụ.

Active-Passive và Active-Active

Mô hình	Cách phục vụ	Điều kiện cần kiểm tra
Active-Passive	Primary phục vụ, standby nhận traffic khi primary unhealthy.	Capacity standby, dữ liệu sẵn sàng, failover và failback.
Active-Active	Nhiều endpoint/pool cùng phục vụ theo steering.	Database replication, session, file/state và consistency giữa các site.

Load Balancer không đồng bộ database hay file. Cần kiểm tra failover bằng giao dịch thực tế và xác nhận ứng dụng vẫn đọc/ghi dữ liệu đúng sau chuyển traffic.

Health check và fallback

Chỉ kiểm TCP port chưa chứng minh app phục vụ được request chính hoặc tới được database.
/health nên phản ánh khả năng phục vụ thực tế, đồng thời tránh dependency phụ gây false failover.
Đối chiếu method, path, port, expected status/body, Host header và yêu cầu TLS/SNI của vhost.
Cho phép traffic monitor hợp lệ qua firewall; một monitor bị chặn có thể báo unhealthy dù user khác truy cập được.
Fallback pool là đích cuối khi các pool còn lại không khả dụng; health của fallback không được dùng để quyết định chuyển traffic tới nó.

Xem Monitor troubleshooting và Endpoint/pool health để đọc health theo quan sát từ Cloudflare thay vì suy ra từ một lần curl local.

Proxied LB và DNS-only LB

Hạng mục	Proxied LB	DNS-only LB
Đường HTTP(S) thông thường	Qua Cloudflare.	Client kết nối endpoint được DNS trả về.
WAF/CDN của HTTP proxy	Có thể áp dụng.	Không áp dụng cho đường trực tiếp.
Origin IP	DNS trả Cloudflare IP.	DNS có thể trả endpoint IP.
Failover	Điều phối request theo health mà không chờ client đổi DNS.	Còn phụ thuộc cache DNS/TTL và hành vi resolver/client.
Session affinity	Public proxied LB có thể dùng `__cflb` hoặc cơ chế được hỗ trợ.	Không hỗ trợ session affinity của proxied LB; xem DNS persistence riêng.

Đối chiếu LB proxy modes khi có CNAME/endpoint trung gian: trạng thái DNS-only ở một hop không mô tả đầy đủ mọi đường request.

Session affinity giữ client trên endpoint khi cookie còn hiệu lực và endpoint còn healthy; không thay thế HA của application/data. Thiết kế stateless hoặc shared session/state thường giúp chuyển endpoint dễ hơn. Xem Session affinity.