SNI là gì? Server Name Indication trong HTTPS và proxy

SNI là gì? SNI, viết tắt của Server Name Indication, là một trường trong bước bắt tay TLS giúp trình duyệt báo cho máy chủ biết nó muốn kết nối tới tên miền nào. Nhờ SNI, một địa chỉ IP có thể phục vụ hàng nghìn website HTTPS với chứng chỉ riêng. Mặt trái là tên miền vẫn lộ ra trên đường truyền dù kết nối đã mã hoá. Bài này ProxyVN giải thích cách SNI hoạt động, vai trò với reverse proxy, proxy, lọc mạng, các lỗi thường gặp và ECH. Tham khảo dịch vụ tại ProxyVN.

Hiểu đúng SNI là gì trong mạng máy tính

Nếu anh em tìm "SNI" trên Google, có thể gặp nhiều nghĩa khác nhau, ví dụ trong xuất nhập khẩu hay trên mạng xã hội. Bài này chỉ nói về nghĩa trong mạng máy tính và bảo mật web. Phần đầu giải thích vấn đề mà SNI sinh ra để giải quyết.

Vấn đề nhiều website chung một IP

Một máy chủ web hay một dịch vụ CDN thường phục vụ rất nhiều website trên cùng một địa chỉ IP. Với HTTP thường, việc phân biệt rất dễ: trình duyệt gửi header Host ghi tên miền, máy chủ đọc và trả về đúng trang. Với HTTPS, mọi chuyện phức tạp hơn. Trước khi gửi bất kỳ header nào, hai bên phải bắt tay TLS, và máy chủ phải trình ra chứng chỉ ngay trong bước đó.

Câu hỏi là máy chủ trình ra chứng chỉ nào khi trên cùng IP có cả trăm website? Nếu không biết trình duyệt muốn vào trang nào, máy chủ chỉ có thể đoán, và đoán sai thì trình duyệt báo lỗi chứng chỉ. Trước khi có SNI, giải pháp là mỗi website HTTPS dùng một IP riêng, vừa tốn kém vừa lãng phí địa chỉ IPv4 vốn đã khan hiếm.

SNI giải quyết thế nào

SNI là phần mở rộng của TLS, được định nghĩa trong RFC 6066 với tên server_name. Trình duyệt ghi tên miền muốn kết nối vào gói tin đầu tiên của bước bắt tay, gọi là ClientHello. Máy chủ đọc tên đó, chọn đúng chứng chỉ và tiếp tục bắt tay. Điểm cần nhớ: SNI giống dòng tên người nhận ghi ngoài phong bì, còn nội dung thư bên trong vẫn được niêm phong.

Bài giải thích SNI là gì của Cloudflare so sánh SNI với việc ghi số căn hộ khi gửi thư tới một toà chung cư: địa chỉ toà nhà là IP, số căn hộ là tên miền.

Mức hỗ trợ hiện nay

Mọi trình duyệt hiện đại, mọi thư viện HTTPS phổ biến như OpenSSL, curl, Python requests, Node.js đều gửi SNI mặc định. Các CDN lớn và phần lớn máy chủ web cũng dựa vào SNI để phục vụ nhiều tên miền. Chỉ những hệ thống rất cũ, như trình duyệt trên Windows XP hay Android đời đầu, mới không gửi SNI, và gần như không còn được hỗ trợ.

Cách SNI hoạt động trong bước bắt tay TLS

Nhiều website chung một địa chỉ IP

Để hiểu vì sao SNI lộ tên miền và vì sao proxy, tường lửa đọc được, cần xem kỹ vị trí của SNI trong bước bắt tay.

Trình tự bắt tay rút gọn

Khi trình duyệt mở một trang HTTPS, các bước diễn ra như sau:

• Trình duyệt phân giải tên miền ra IP qua DNS.
• Trình duyệt mở kết nối TCP tới IP đó ở cổng 443.
• Trình duyệt gửi ClientHello, trong đó có trường SNI ghi tên miền, danh sách bộ mã hoá, phiên bản TLS và danh sách giao thức ALPN như h2, http/1.1.
• Máy chủ đọc SNI, chọn chứng chỉ phù hợp, trả về ServerHello cùng chứng chỉ.
• Hai bên thống nhất khoá, từ đây mọi dữ liệu được mã hoá.

Điểm mấu chốt nằm ở bước thứ ba. ClientHello được gửi trước khi có khoá mã hoá, nên SNI đi ở dạng rõ, ai đứng giữa đường truyền cũng đọc được.

SNI khác header Host thế nào

Nhiều anh em nhầm SNI với header Host. Hai thứ cùng chứa tên miền nhưng nằm ở hai tầng khác nhau:

Thông thường SNI và Host trùng nhau. Nhiều CDN hiện từ chối yêu cầu khi hai giá trị này không khớp, để chặn kỹ thuật domain fronting từng bị lạm dụng.

Khi không có SNI hoặc SNI sai

Nếu ClientHello không có SNI, máy chủ trả về chứng chỉ mặc định. Nếu chứng chỉ đó không chứa tên miền trình duyệt cần, trình duyệt báo lỗi tên không khớp. Nếu SNI ghi một tên mà máy chủ không phục vụ, máy chủ có thể gửi cảnh báo unrecognized_name theo RFC 6066, trả chứng chỉ mặc định, hoặc đóng kết nối, tuỳ cấu hình.

Kiểm tra SNI bằng dòng lệnh

Tên miền nằm trong ClientHello

Muốn thấy SNI hoạt động, cách nhanh nhất là dùng openssl và curl. Đây cũng là cách ProxyVN hay dùng khi khoanh vùng lỗi chứng chỉ trên máy chủ có nhiều tên miền.

Dùng openssl s_client

Tham số -servername chỉ định giá trị SNI gửi đi. So sánh kết quả khi có và không có SNI sẽ thấy rõ máy chủ chọn chứng chỉ khác nhau:

# Gửi SNI là example.com, xem chứng chỉ máy chủ trả về
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
 
# Không gửi SNI (OpenSSL 1.1.1 trở lên dùng -noservername)
openssl s_client -connect example.com:443 -noservername </dev/null 2>/dev/null | openssl x509 -noout -subject
 
# Kết nối tới một IP cụ thể nhưng gửi SNI của tên miền khác
openssl s_client -connect 203.0.113.10:443 -servername shop.vi-du.vn </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

Nếu dòng subject hoặc subjectAltName ở lệnh đầu chứa đúng tên miền, SNI hoạt động bình thường. Lệnh thứ hai thường trả về chứng chỉ mặc định của máy chủ. Lệnh thứ ba hữu ích khi chuyển website sang máy chủ mới, cần kiểm tra chứng chỉ trước khi đổi DNS.

Dùng curl với --resolve và --connect-to

curl gửi SNI theo tên miền trong URL. Tham số --resolve ép tên miền phân giải ra một IP cụ thể, còn --connect-to chuyển kết nối sang máy khác. Cả hai đều giữ nguyên SNI theo tên miền gốc:

# Thử website trên máy chủ mới trước khi đổi DNS
curl -v --resolve shop.vi-du.vn:443:203.0.113.10 https://shop.vi-du.vn/
 
# Gửi yêu cầu tới máy khác nhưng giữ SNI và Host là shop.vi-du.vn
curl -v --connect-to shop.vi-du.vn:443:203.0.113.10:443 https://shop.vi-du.vn/

Trong kết quả -v, dòng "Server certificate" và "subject" cho biết chứng chỉ nhận được. Nếu thấy "SSL: no alternative certificate subject name matches target host name", máy chủ trả sai chứng chỉ cho SNI đó.

Xem SNI bằng Wireshark

Với Wireshark, anh em dùng bộ lọc tls.handshake.extensions_server_name để chỉ hiện các gói ClientHello có SNI. Mở một gói, mục Extension: server_name hiện rõ tên miền. Đây là minh hoạ trực quan nhất cho việc SNI đi ở dạng rõ, kể cả khi trang web dùng HTTPS.

SNI trong reverse proxy và cân bằng tải

Reverse proxy định tuyến theo SNI

Với người vận hành máy chủ, SNI không chỉ để chọn chứng chỉ mà còn để định tuyến kết nối tới đúng máy chủ phía sau. Phần này đi qua hai cách làm phổ biến.

Kết thúc TLS tại reverse proxy

Cách phổ biến nhất là reverse proxy như Nginx giữ chứng chỉ của mọi tên miền, giải mã TLS, rồi chuyển yêu cầu HTTP tới máy chủ ứng dụng phía sau. Nginx dùng SNI để chọn khối server có server_name phù hợp. Cách cấu hình Nginx làm reverse proxy đầy đủ có trong bài cách cấu hình Nginx làm reverse proxy.

server {
    listen 443 ssl;
    server_name shop.vi-du.vn;
    ssl_certificate     /etc/ssl/shop/fullchain.pem;
    ssl_certificate_key /etc/ssl/shop/privkey.pem;
    location / { proxy_pass http://127.0.0.1:3000; }
}
 
server {
    listen 443 ssl;
    server_name blog.vi-du.vn;
    ssl_certificate     /etc/ssl/blog/fullchain.pem;
    ssl_certificate_key /etc/ssl/blog/privkey.pem;
    location / { proxy_pass http://127.0.0.1:4000; }
}

Hai khối server cùng lắng nghe cổng 443 trên một IP. Nhờ SNI, Nginx biết trình chứng chỉ nào và chuyển yêu cầu tới ứng dụng nào. Đây là ví dụ cấu hình chung, đường dẫn chứng chỉ thay theo máy của anh em.

Định tuyến theo SNI mà không giải mã

Cách thứ hai là chỉ đọc SNI rồi chuyển nguyên kết nối TLS tới máy chủ phía sau, không giải mã. Máy chủ phía sau tự giữ chứng chỉ và tự giải mã. Nginx làm việc này bằng mô-đun ngx_stream_ssl_preread_module, có từ bản 1.11.5. Mô-đun này cho phép lấy thông tin từ ClientHello mà không kết thúc TLS, và không được biên dịch mặc định, cần tham số --with-stream_ssl_preread_module.

Ví dụ cấu hình chọn máy chủ phía sau theo tên miền, lấy từ tài liệu Nginx:

map $ssl_preread_server_name $name {
    backend.example.com      backend;
    default                  backend2;
}
 
upstream backend {
    server 192.168.0.1:12345;
    server 192.168.0.2:12345;
}
 
upstream backend2 {
    server 192.168.0.3:12345;
    server 192.168.0.4:12345;
}
 
server {
    listen      12346;
    proxy_pass  $name;
    ssl_preread on;
}

Biến $ssl_preread_server_name chứa tên miền đọc từ SNI. Mô-đun còn có $ssl_preread_alpn_protocols chứa danh sách giao thức ALPN, và $ssl_preread_protocol chứa phiên bản TLS cao nhất mà client hỗ trợ. Tài liệu Nginx có ví dụ dùng biến cuối để chạy cả SSH và HTTPS trên cùng cổng 443: khi biến rỗng, kết nối không phải TLS, chuyển sang SSH.

HAProxy định tuyến theo SNI

HAProxy cũng làm được việc tương tự ở chế độ TCP. Ví dụ dưới đây là cấu hình triển khai chung:

frontend https_in
    bind *:443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    use_backend shop if { req_ssl_sni -i shop.vi-du.vn }
    use_backend blog if { req_ssl_sni -i blog.vi-du.vn }
    default_backend web_mac_dinh
 
backend shop
    mode tcp
    server s1 10.0.0.11:443

Định tuyến theo SNI phù hợp khi máy chủ phía sau cần tự giữ khoá riêng, ví dụ mỗi khách hàng một máy chủ, hoặc khi cần chuyển tiếp giao thức không phải HTTP chạy trên TLS.

SNI và proxy, tường lửa, nhà mạng

Vì SNI đi ở dạng rõ, mọi thiết bị đứng giữa đường truyền đều đọc được tên miền anh em truy cập. Phần này giải thích ảnh hưởng tới người dùng proxy.

Proxy HTTP CONNECT thấy gì

Khi trình duyệt dùng proxy HTTP để vào trang HTTPS, nó gửi yêu cầu CONNECT kèm tên miền và cổng, ví dụ CONNECT shop.vi-du.vn:443. Proxy mở đường hầm tới đích và chuyển dữ liệu hai chiều. Proxy thấy tên miền qua yêu cầu CONNECT, và thấy thêm qua SNI trong ClientHello đi qua đường hầm. Nội dung trang, đường dẫn cụ thể, cookie, mật khẩu vẫn được mã hoá đầu cuối. Cơ chế đường hầm được giải thích kỹ trong bài proxy tunnel là gì.

Với proxy SOCKS5, client có thể gửi tên miền hoặc IP cho proxy. Dù gửi IP, SNI trong ClientHello vẫn chứa tên miền. Vì vậy dùng SOCKS5 với phân giải DNS tại máy cũng không giấu được tên miền với proxy.

Tường lửa và mạng công ty lọc theo SNI

Nhiều tường lửa thế hệ mới và bộ lọc web công ty đọc SNI để chặn hoặc cho phép website mà không cần giải mã HTTPS. Cách làm này nhẹ hơn nhiều so với giải mã toàn bộ lưu lượng. Đây cũng là một trong những cách nhà mạng hay tổ chức có thể chặn truy cập theo tên miền. Dấu hiệu khi bị chặn theo SNI thường là kết nối bị cắt ngay sau ClientHello, trình duyệt báo ERR_CONNECTION_RESET.

Nếu nghi ngờ nhà mạng can thiệp vào kết nối proxy, bài nhà mạng chặn proxy hướng dẫn cách nhận biết và khắc phục.

SNI và dấu vân tay TLS

Ngoài SNI, ClientHello còn chứa danh sách bộ mã hoá, phần mở rộng, phiên bản TLS theo một thứ tự đặc trưng cho từng loại trình duyệt hay thư viện. Các hệ thống chống bot dùng thông tin này để tạo dấu vân tay TLS như JA3, JA4. Đổi IP qua proxy không đổi được dấu vân tay này. Chủ đề được phân tích riêng trong bài TLS fingerprint JA3 và proxy.

Proxy HTTPS và SNI của chính proxy

Với proxy HTTPS, tức kết nối từ trình duyệt tới proxy được mã hoá, trình duyệt gửi SNI là tên của máy chủ proxy khi bắt tay với proxy. Nếu khai báo proxy bằng IP thay vì tên, SNI có thể rỗng và proxy trả chứng chỉ mặc định, dẫn tới lỗi chứng chỉ. Khái niệm proxy SSL được giải thích trong bài proxy SSL là gì.

Các lỗi thường gặp liên quan tới SNI

Lỗi SNI thường xuất hiện với người vận hành máy chủ, người viết script, và người dùng thư viện cũ. Phần này liệt kê các lỗi hay gặp kèm cách xử lý.

Lỗi tên không khớp chứng chỉ

Thông báo kiểu "certificate is not valid for the requested host", "SSL: no alternative certificate subject name matches" hay NET::ERR_CERT_COMMON_NAME_INVALID trong Chrome nghĩa là chứng chỉ nhận được không chứa tên miền đang truy cập. Nguyên nhân liên quan SNI:

• Client không gửi SNI, máy chủ trả chứng chỉ mặc định.
• Máy chủ chưa cấu hình khối server cho tên miền đó, rơi vào khối mặc định.
• Script kết nối bằng IP thay vì tên miền, SNI rỗng.
• Reverse proxy chuyển tiếp TLS tới máy chủ phía sau nhưng không truyền SNI.

Lỗi unrecognized_name

Một số máy chủ gửi cảnh báo unrecognized_name khi SNI không khớp tên nào đã cấu hình. Thư viện cũ như Java phiên bản cũ coi cảnh báo này là lỗi nghiêm trọng và dừng kết nối, báo "handshake alert: unrecognized_name". Cách sửa phía máy chủ là thêm tên miền đó vào cấu hình hoặc tắt cảnh báo. Phía client, cập nhật thư viện lên bản mới.

Lỗi SNI không khớp Host

Nhiều CDN trả lỗi 421 Misdirected Request hoặc 403 khi SNI và header Host khác nhau. Lỗi này hay gặp khi viết script tự đặt header Host khác với tên miền trong URL, hoặc khi dùng lại kết nối HTTP/2 cho một tên miền khác. Cách sửa là để thư viện tự đặt Host theo URL.

Reverse proxy không truyền SNI lên máy chủ gốc

Khi Nginx chuyển tiếp tới máy chủ gốc qua HTTPS, mặc định nó không gửi SNI. Nếu máy chủ gốc ở sau CDN hoặc phục vụ nhiều tên miền, kết nối sẽ lỗi. Cần bật proxy_ssl_server_name:

location / {
    proxy_pass https://origin.vi-du.vn;
    proxy_ssl_server_name on;
    proxy_ssl_name origin.vi-du.vn;
}

Đây là một lỗi rất hay gặp khi chuyển máy chủ gốc ra sau CDN, và chỉ cần hai dòng cấu hình là sửa được.

Cấu hình SNI an toàn khi vận hành máy chủ

Với người tự vận hành máy chủ web hay reverse proxy, vài thiết lập liên quan tới SNI giúp tránh lộ thông tin và giảm lỗi chứng chỉ. Đây là những điểm ProxyVN thấy hay bị bỏ qua nhất.

Chặn kết nối có SNI lạ

Khi ai đó kết nối tới IP máy chủ mà không gửi SNI, hoặc gửi một tên miền không có trên máy, Nginx sẽ dùng khối server mặc định. Nếu khối mặc định là website chính, máy chủ vô tình trả chứng chỉ thật cho bất kỳ ai quét IP. Công cụ quét Internet dựa vào điều này để ghép IP với tên miền, kể cả khi website đã giấu IP thật sau CDN.

Từ bản 1.19.4, Nginx có chỉ thị ssl_reject_handshake để từ chối bắt tay ở khối mặc định mà không cần chứng chỉ giả. Ví dụ cấu hình triển khai chung:

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;
}

Với cấu hình này, chỉ những kết nối gửi đúng SNI của các tên miền đã khai báo mới nhận được chứng chỉ. Kết nối quét bằng IP sẽ bị từ chối ngay ở bước bắt tay.

Chọn loại chứng chỉ phù hợp

Mỗi tên miền có thể dùng chứng chỉ riêng, hoặc gom nhiều tên vào một chứng chỉ. Bảng dưới so sánh ba cách phổ biến:

Chứng chỉ nhiều tên tiện nhưng làm lộ danh sách tên miền dùng chung máy chủ. Nếu không muốn người ngoài biết các website có liên quan với nhau, nên dùng chứng chỉ riêng cho từng tên miền, để SNI chọn đúng chứng chỉ cho từng kết nối.

Nhật ký minh bạch chứng chỉ

Mọi chứng chỉ do tổ chức cấp phát công khai cấp ra đều được ghi vào nhật ký Certificate Transparency. Bất kỳ ai cũng có thể tra cứu tên miền con của một website qua các nhật ký này. Vì vậy giấu tên miền con bằng cách không công bố DNS là không đủ, nếu tên đó có chứng chỉ riêng. Với hệ thống nội bộ, dùng chứng chỉ wildcard hoặc CA nội bộ giúp hạn chế lộ tên.

Theo dõi lỗi bắt tay

Nhật ký lỗi của Nginx ghi lại các lần bắt tay thất bại. Số lỗi tăng đột ngột thường do chứng chỉ hết hạn, cấu hình SNI sai sau khi thêm tên miền mới, hoặc client cũ không gửi SNI. Đặt cảnh báo khi số lỗi vượt ngưỡng giúp phát hiện sớm trước khi khách hàng báo.

ECH mã hoá SNI

ECH mã hoá cả tên miền

Vì SNI lộ tên miền, giới bảo mật đã phát triển cách mã hoá nó. Giải pháp hiện tại là ECH, viết tắt của Encrypted Client Hello.

Từ ESNI tới ECH

Phiên bản đầu tiên là ESNI, chỉ mã hoá riêng trường SNI. Theo bài tạm biệt ESNI, chào ECH của Cloudflare, Cloudflare và Firefox bật ESNI ở chế độ tuỳ chọn từ năm 2018. ESNI có nhược điểm: nếu giải mã thất bại, máy chủ huỷ kết nối, và các thông tin khác trong ClientHello vẫn lộ. ECH ra đời để thay thế, mã hoá toàn bộ ClientHello.

ClientHelloOuter và ClientHelloInner

ECH chia ClientHello làm hai phần:

• ClientHelloOuter gửi ở dạng rõ như bình thường, chứa SNI của nhà cung cấp dịch vụ ECH, tức máy chủ tiếp nhận, không phải website thật.
• ClientHelloInner được mã hoá và gửi kèm như một phần mở rộng của Outer. Phần này chứa tên miền thật và danh sách ALPN.

Nếu giải mã thành công, máy chủ dùng phần Inner. Nếu thất bại, máy chủ hoàn tất bắt tay theo phần Outer và gửi khoá công khai đúng để client thử lại, thay vì huỷ kết nối như ESNI.

Khoá công khai lấy từ DNS

Khoá công khai để mã hoá phần Inner được công bố trong DNS, qua bản ghi loại HTTPS mới, và nên được lấy qua DNS over HTTPS để không bị can thiệp. Điều này có nghĩa là ECH hoạt động tốt nhất khi kết hợp với DNS mã hoá. Nếu DNS vẫn đi dạng rõ, người đứng giữa vẫn thấy tên miền qua truy vấn DNS.

Tình trạng triển khai

Bài viết năm 2020 của Cloudflare ghi rằng ECH khi đó vẫn đang hoàn thiện. Từ năm 2023, các trình duyệt lớn như Chrome và Firefox đã bật ECH mặc định khi DNS trả về cấu hình ECH, và Cloudflare bật ECH cho các tên miền dùng dịch vụ của họ. Tuy vậy, mức độ phổ biến vẫn phụ thuộc vào việc website và DNS có hỗ trợ hay không. Nhiều mạng công ty chặn ECH để giữ khả năng lọc theo SNI.

ECH ảnh hưởng tới người dùng proxy thế nào

Với proxy HTTP CONNECT, proxy vẫn thấy tên miền trong yêu cầu CONNECT, nên ECH không giấu được tên miền với proxy. Với proxy SOCKS5 nhận IP thay vì tên miền, kết hợp DNS mã hoá và ECH, proxy chỉ thấy IP và SNI của máy chủ tiếp nhận. Với tường lửa lọc theo SNI, ECH khiến việc lọc khó hơn, vì SNI bên ngoài chỉ là tên chung của CDN.

SNI trong lập trình và thu thập dữ liệu

Với anh em viết script gọi HTTPS qua proxy, hiểu SNI giúp tránh vài lỗi khó hiểu.

Thư viện tự gửi SNI theo URL

Python requests, Node.js fetch, Go net/http, curl đều tự gửi SNI theo tên miền trong URL. Anh em không cần cấu hình gì thêm. Lỗi chỉ xuất hiện khi gọi bằng IP rồi tự đặt header Host. Ví dụ triển khai đúng với Python khi cần gọi một IP cụ thể nhưng vẫn giữ SNI là cách dùng thư viện hỗ trợ ghi đè phân giải tên, thay vì đổi URL sang IP.

import requests
 
proxies = {
    "http": "http://user:pass@203.0.113.10:8080",
    "https": "http://user:pass@203.0.113.10:8080",
}
# Thư viện gửi CONNECT shop.vi-du.vn:443 tới proxy, rồi gửi SNI shop.vi-du.vn
r = requests.get("https://shop.vi-du.vn/", proxies=proxies, timeout=20)
print(r.status_code)

Proxy nhận tên miền trong CONNECT, phân giải DNS phía proxy, và SNI trong ClientHello khớp với Host. Đây là cách hoạt động mặc định, ít lỗi nhất.

Proxy cần ổn định và đúng giao thức

Khi chạy nhiều kết nối HTTPS qua proxy, kết nối bị cắt sau ClientHello thường là dấu hiệu proxy chập chờn hoặc mạng bị lọc. Khi cần IP Việt Nam ổn định cho công việc, anh em có thể mua proxy tại ProxyVN với proxy dân cư và datacenter hỗ trợ HTTP CONNECT và SOCKS5.

SNI là dòng chữ duy nhất ngoài phong bì HTTPS. Biết ai đọc được dòng chữ đó giúp anh em hiểu HTTPS bảo vệ được gì và không bảo vệ được gì.

ProxyVN đảm bảo mạng kết nối luôn ổn định, proxy chất lượng không bị mất kết nối, và hỗ trợ 24/24 khi anh em gặp lỗi kết nối HTTPS qua proxy.

Kết luận

SNI là gì? Đó là trường trong ClientHello giúp máy chủ biết tên miền cần chứng chỉ nào, cho phép nhiều website HTTPS dùng chung IP, nhưng làm lộ tên miền trên đường truyền. Reverse proxy, tường lửa và proxy đều dựa vào SNI, còn ECH là hướng mã hoá nó. Cần proxy ổn định cho HTTPS, hãy liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khi tìm hiểu SNI là gì.