Lỗi 421 Misdirected Request và cách kiểm Host SNI

lỗi 421 Misdirected Request cần được kiểm ở quan hệ giữa kết nối và origin mà request nhắm tới. Anh em nên phân biệt tên trong TLS với authority của HTTP, kiểm tuyến virtual host và việc tái sử dụng kết nối trước khi sửa cấu hình mạng. ProxyVN hướng dẫn anh em kiểm đúng lớp gây lỗi và giữ bằng chứng trước khi thay cấu hình.

Lỗi 421 Misdirected Request và origin của request

Mã 421 cho biết server nhận request không thể phục vụ tổ hợp origin mà request yêu cầu. MDN mô tả 421 theo tổ hợp scheme và authority, đồng thời nêu tình huống liên quan tái sử dụng kết nối. Vì vậy, không nên xem đây là một tên khác của lỗi đăng nhập proxy. Cần xác định request đã tới server nào và server đó đang được cấu hình cho những origin nào trên kết nối hiện tại.

Một địa chỉ IP có thể phục vụ nhiều tên miền. Kết nối tới đúng IP chưa đủ chứng minh request thuộc đúng virtual host; tên trong TLS và tên ở lớp HTTP còn ảnh hưởng quá trình lựa chọn. Nếu ứng dụng tự thay URL thành IP rồi chỉ thêm Host, nó có thể tạo ra tổ hợp khác với việc gọi tên miền gốc. Bài kiểm cần giữ rõ các trường thay vì gọi chung tất cả là tên server.

Scheme và authority tạo ngữ cảnh

Authority thường gồm hostname và cổng trong URI, còn scheme phân biệt cách truy cập như HTTP hay HTTPS. Một tên miền trên cổng khác hoặc giao thức khác có thể thuộc cấu hình phục vụ khác. Không nên chỉ so chuỗi hostname rồi nhận rằng hai request có cùng origin. Khi tái hiện, ghi URL đầy đủ đã che phần nhạy cảm và cổng thực, nhất là ở môi trường có TLS termination hoặc nhiều listener dùng chung máy.

Nếu có redirect, URL cuối có thể khác origin ban đầu. Client cần áp quy tắc kết nối và credential theo đích mới, không giữ các giả định của lượt trước một cách máy móc. Lưu chuỗi redirect rút gọn để biết 421 xuất hiện ở đâu. Một request tới trang A rồi được chuyển sang B không giống việc gọi A nhưng sửa Host thành B trên cùng kết nối; hai ca cần được đặt tên và kiểm riêng.

Phân biệt với lỗi xác thực gateway

407 là tín hiệu yêu cầu xác thực proxy, còn 421 thuộc quan hệ request và server có khả năng phục vụ nó. Theo ngữ nghĩa 421 trong RFC 9110, proxy không được tạo mã này theo vai trò proxy. Nếu hệ thống quan sát được 421 qua một gateway, cần phân biệt gateway chuyển tiếp response từ server với một triển khai dùng mã không theo ngữ nghĩa chuẩn. Không quy nguồn phát chỉ từ việc client có đặt proxy.

Một mật khẩu gateway sai có thể làm request dừng ở 407 trước khi tới TLS origin. Sửa password trong trường hợp đó chỉ giải quyết bước xác thực trung gian. Nếu sau đó có 421, đó là sự kiện ở bước khác cần bằng chứng riêng. Log nên giữ thứ tự các giai đoạn để đội hỗ trợ biết đã đi qua phần nào, thay vì gộp mọi lần lỗi trong phiên thành một vấn đề chung rồi thay credential liên tục.

Lỗi 421 Misdirected Request và tên SNI trong TLS

SNI là thông tin tên mà client có thể đưa vào bắt tay TLS để server chọn ngữ cảnh phù hợp. RFC về TLS extensions mô tả cơ chế server_name; nó khác với header Host được gửi trong thông điệp HTTP sau đó. Thay Host không tự thay SNI của kết nối đã bắt tay. Điểm này cần giữ rõ khi dùng công cụ kiểm virtual host hoặc khi một reverse proxy nối TLS tới upstream.

Kiểm chứng chỉ trước khi đọc status

Client cần kiểm chain và tên chứng chỉ theo cấu hình tin cậy của nó. Nếu tên yêu cầu không nằm trong phạm vi chứng chỉ phù hợp, lỗi có thể xảy ra trước khi có response HTTP. Trong tình huống đó, không ghi status 421 vì client chưa nhận được nó. Một báo cáo đúng nên nói TLS verification error, giữ tên dự kiến và thông tin chứng chỉ không bí mật cần thiết để nhóm quản lý kiểm lại.

Đừng tắt kiểm chứng chỉ chỉ để tiếp tục tới một trang lỗi rồi nhận rằng TLS đã ổn. Việc tắt kiểm làm mất một điều kiện quan trọng của phép thử. Trong lab, dùng chứng chỉ thử được client tin cậy qua một CA file riêng và có SAN phù hợp với hai tên lab. Cách đó cho phép tạo ca HTTP sau TLS mà vẫn giữ kiểm chứng chỉ, giúp phân biệt lỗi định tuyến ứng dụng với lỗi tin cậy chứng chỉ.

Host ở HTTP1 và authority ở HTTP2

Với HTTP/1.1, Host là trường quen thuộc để xác định host đích. Với HTTP/2, pseudo-header :authority cùng các thành phần khác biểu diễn ngữ cảnh request theo giao thức. Không nên tự thêm :authority bằng một header thường trong client HTTP/1.1 rồi gọi đó là thử H2. Cần dùng một client hỗ trợ giao thức thật và xác nhận giao thức thương lượng, vì các quy tắc tái sử dụng kết nối có liên quan tới lớp đó.

Một trường hợp Host/SNI không khớp không buộc mọi server trả 421. Server có thể có chính sách hoặc cấu hình virtual host khác, miễn cần được đánh giá theo sản phẩm và vai trò. Fixture trong bài chọn 421 để làm đối chứng rõ về tổ hợp không được phục vụ. Khi áp vào Apache, NGINX hay load balancer, đọc tài liệu đúng bản và kiểm log trước khi suy ra rằng mọi sai tên phải có cùng một biểu hiện.

TLS SNI và HTTP Host

Lỗi 421 Misdirected Request trong lab hai virtual host

Lab dùng hai tên a.lab.test và b.lab.test trên loopback, với chứng chỉ thử có cả hai tên trong SAN. Server lưu SNI từ callback TLS rồi so với Host của request HTTP/1.1. Nếu tên khớp và thuộc hai host lab, nó trả 200; nếu không khớp, nó trả 421. Quy tắc này do fixture đặt ra để kiểm quan hệ giữa hai lớp, không phải một bộ virtual hosting dùng cho môi trường sản xuất.

Phần server cần quan sát

import ssl
from http.server import BaseHTTPRequestHandler, HTTPServer
 
class VirtualHost(BaseHTTPRequestHandler):
    def do_GET(self):
        sni = getattr(self.connection, 'lab_sni', None)
        host = self.headers.get('Host', '').split(':')[0]
        allowed = host in ('a.lab.test', 'b.lab.test')
        self.send_response(200 if allowed and sni == host else 421)
        self.send_header('Content-Length', '0')
        self.end_headers()
 
context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain('cert.pem', 'key.pem')
context.set_servername_callback(
    lambda sock, name, ctx: setattr(sock, 'lab_sni', name)
)
server = HTTPServer(('127.0.0.1', 8772), VirtualHost)
server.socket = context.wrap_socket(server.socket, server_side=True)
server.serve_forever()

Mẫu cần cert.pem và key.pem được tạo cho lab, không dùng khóa riêng của dịch vụ thật. Chứng chỉ phải hợp lệ cho cả hai tên và được client tin cậy qua file riêng. Tài liệu ssl của Python giải thích các API SSLContext và kiểm tên. Trong phép thử của bài, chứng chỉ chỉ dùng cục bộ và không được cài vào kho tin cậy toàn máy; điều đó giúp giới hạn ảnh hưởng của môi trường thử.

Client giữ kiểm chứng chỉ

import socket
import ssl
 
context = ssl.create_default_context(cafile='cert.pem')
for sni, host in (
    ('a.lab.test', 'a.lab.test'),
    ('a.lab.test', 'b.lab.test'),
    ('b.lab.test', 'b.lab.test'),
):
    with socket.create_connection(('127.0.0.1', 8772), timeout=2) as raw:
        with context.wrap_socket(raw, server_hostname=sni) as conn:
            request = f'GET / HTTP/1.1\r\nHost: {host}\r\nConnection: close\r\n\r\n'
            conn.sendall(request.encode('ascii'))
            print(sni, host, conn.recv(2048).split(b'\r\n', 1)[0])

Trong kiểm thử thực chạy, hai cặp tên khớp cho 200, còn SNI a với Host b cho 421 theo quy tắc fixture. Một ca thêm dùng tên wrong.lab.test ngoài SAN gây lỗi kiểm chứng chỉ trước HTTP. Sự khác biệt cho thấy tại sao cần giữ lỗi TLS và status HTTP riêng. Không có HTTP/2, CONNECT hay gateway thương mại trong lab này; kết quả không xác nhận cơ chế coalescing trên H2 đã được tái hiện.

Bảng phải ghi rõ quy tắc của fixture

Nếu một server khác trả 200 cho SNI a và Host b, điều đó không tự làm nó sai theo cùng tiêu chí của lab. Có thể nó được cấu hình phục vụ cả hai origin trong ngữ cảnh kết nối đó. Cần so với cấu hình dự kiến và tài liệu sản phẩm, không áp quy tắc so chuỗi của fixture như một yêu cầu chung của TLS. Giá trị của lab nằm ở việc có một trường hợp kiểm soát được để học cách phân biệt lớp lỗi.

Khi chạy lại, chọn cổng chưa dùng và kiểm server thực đang nhận request. Nếu cổng cũ thuộc một tiến trình khác, bảng status có thể khiến người đọc hiểu nhầm kết quả. Đặt nhãn lab trong log hoặc dùng endpoint riêng để nhận diện. Sau khi thử, dừng listener và quản lý khóa thử theo thư mục lab; không phát hành khóa riêng cùng một gói hướng dẫn dành cho sử dụng ngoài môi trường kiểm soát.

Hai virtual host trong lab

Lỗi 421 Misdirected Request và tái sử dụng kết nối

Một client hiện đại có thể tái sử dụng kết nối thay vì mở mới cho mỗi request, nhưng khả năng đó có điều kiện theo giao thức và origin. RFC HTTP/2 mô tả các quy tắc kết nối và authority liên quan. Một chứng chỉ có nhiều tên không tự chứng minh server được cấu hình phục vụ mọi tên đó trên một kết nối cụ thể. Client và server cần có cách xử lý khi request được đưa tới ngữ cảnh không phù hợp.

So kết nối mới và pool hiện tại

Khi lỗi chỉ xuất hiện sau một chuỗi request, ghi thứ tự origin và cách client quản lý pool. Một ca có kết nối mới có thể giúp khoanh vùng ảnh hưởng của tái sử dụng, nhưng cần giữ cùng URL và cấu hình xác thực. Không kết luận mọi 421 do pool chỉ từ việc khởi động lại ứng dụng làm lỗi tạm biến mất. Lần khởi động lại cũng có thể đổi DNS, thời điểm hoặc trạng thái cấu hình mà anh em chưa đo.

Nếu cần kiểm H2, xác nhận client và server thực thương lượng H2, ghi connection ID hoặc trace tương ứng nếu có. So các request trên cùng kết nối với request qua kết nối riêng theo chính sách của client. Đừng chỉ thêm một cờ dòng lệnh mà không kiểm bản curl có hỗ trợ HTTP/2; binary trên máy có thể thiếu tính năng đó. Trong bài này, ca H2 vẫn là bước cần kiểm riêng khi môi trường có đủ công cụ.

Retry qua kết nối khác cần có giới hạn

Ngữ nghĩa 421 cho phép client thử lại qua kết nối khác, nhưng ứng dụng vẫn cần quản lý số lần và trạng thái tác vụ. Nếu việc phát lại không tạo kết nối phù hợp hoặc cùng tuyến vẫn chọn sai server, retry vô hạn không sửa nguyên nhân. Theo dõi số lần thử thực ở client và upstream, vì nhiều tầng có thể cùng phát lại. Sau một ngân sách nhỏ theo thiết kế, chuyển sang điều tra cấu hình thay vì tiếp tục tăng tải.

Với request có body, client cần khả năng phát lại nội dung và chính sách của thư viện phải được hiểu. Một stream đã đọc hết không thể tự phát lại chỉ bằng việc gọi lại cùng đối tượng. Đồng thời, giữ idempotency theo hợp đồng API nếu có tác dụng phụ. Không áp một cơ chế retry chung cho mọi lỗi mạng rồi bỏ qua tính chất của thao tác; ca kiểm cần xác nhận cả kết nối mới lẫn kết quả nghiệp vụ không bị nhân đôi.

Lỗi 421 Misdirected Request khi kiểm reverse proxy

Một reverse proxy chấm dứt TLS từ client có thể mở một kết nối TLS mới tới upstream. Khi đó có hai phía tên cần quản lý: tên công khai và tên upstream. Header HTTP gửi vào upstream cùng SNI dùng cho kết nối upstream có thể cần cấu hình theo hợp đồng của backend. Không phải mọi hệ thống đều phải giữ cùng tên ở hai phía, nhưng mỗi phía phải đúng với origin mà bên nhận được cấu hình phục vụ.

Vẽ hai kết nối riêng

Sơ đồ nên có client tới frontend và frontend tới backend, ghi protocol, hostname, cổng và điểm kiểm chứng chỉ của từng đoạn. Nếu chỉ có một ô tên miền, đội vận hành dễ sửa SNI phía client trong khi lỗi nằm ở SNI upstream. Kiểm log của cả hai phía theo mã tương quan để biết status 421 được tạo ở frontend hay được chuyển tiếp từ backend. Không gán nguồn phát chỉ dựa vào địa chỉ mà client trực tiếp kết nối.

Với upstream dùng chứng chỉ cho một tên nội bộ, cấu hình tin cậy và tên kiểm phải theo thiết kế đó. Không tắt xác minh để bỏ một lỗi certificate rồi xem mọi 421 còn lại là lỗi HTTP độc lập. Giữ các bước kiểm TLS như điều kiện trước khi đánh giá response. Nếu backend chỉ phục vụ một Host cụ thể, xác nhận header thực được chuyển và không có middleware ghi đè sau nơi anh em đã kiểm cấu hình.

DNS và cân bằng tải cần kiểm cùng ngữ cảnh

Một nhóm IP sau cùng hostname có thể không có cấu hình đồng nhất trong lúc triển khai. Nếu lỗi chỉ xảy ra ở một phần kết nối, ghi đích mạng thực và phiên bản backend tương ứng khi được phép. Không đổi DNS toàn hệ thống từ một máy kiểm rồi kết luận đã sửa. Cần xác định node nào phục vụ sai và đưa cấu hình về trạng thái dự kiến qua quy trình quản lý, đồng thời giữ ca đối chứng cho node đang hoạt động đúng.

Nếu dùng công cụ ép kết nối tới IP cụ thể trong môi trường được quản lý, vẫn phải giữ hostname dự kiến cho TLS và HTTP. Tài liệu curl có các tùy chọn phục vụ kiểm tuyến, nhưng cần dùng theo quyền truy cập và kiểm request thực. Gọi trực tiếp https://IP rồi thêm Host có thể không tương đương, vì SNI và tên kiểm chứng chỉ không tự đổi theo header mà anh em thêm ở lớp HTTP.

Kết nối mới và pool

Lỗi 421 Misdirected Request và forward proxy

Với HTTPS qua một HTTP forward proxy, client thường thiết lập tunnel tới authority rồi thực hiện TLS bên trong. Cần ghi riêng kết quả CONNECT, tên dùng trong TLS và request HTTP sau đó. Một tunnel thành công chỉ chứng minh bước nối trung gian đã được chấp nhận; nó chưa xác nhận origin phục vụ đúng virtual host. Nếu bước TLS thất bại, client chưa có status HTTP của API để ghi 421.

Xác nhận tuyến mà không đổi danh tính origin

Khi cấu hình proxy, giữ URL của tài nguyên là hostname dự kiến của dịch vụ. Đừng đổi URL thành địa chỉ proxy rồi cố sửa Host để gọi API, vì đó là thay cách định danh origin chứ không chỉ đổi tuyến. Anh em có thể xem định dạng proxy để tách địa chỉ gateway khỏi URL đích. Credential gateway cũng cần được cấp ở trường riêng theo thư viện thay vì lẫn vào Authorization của API.

Nếu có no_proxy, kiểm phạm vi hiệu lực trên client đang dùng. Một lượt được gọi là qua proxy có thể thực tế bypass theo hostname. Khi so trực tiếp với qua tunnel trong môi trường được phép, dùng cùng origin và cùng nội dung request, rồi xác nhận tại điểm quan sát phù hợp. Nếu không có quyền xem tunnel, ghi giới hạn đó thay vì coi biến môi trường là bằng chứng đường đi đã được thực hiện.

Sửa auth không sửa Host SNI

Một đường mạng có credential hợp lệ vẫn có thể đưa request tới server không phục vụ origin theo cấu hình hiện tại. Vì vậy, status 407 đã hết không phải bằng chứng bài toán 421 cũng được giải quyết. Hãy kiểm lần lượt: xác thực gateway, thiết lập tunnel, xác minh TLS rồi response HTTP. Khi lưu bằng chứng, dùng nhãn từng giai đoạn để người nhận không nhầm mã thành công của lớp trước với kết quả cuối của ứng dụng.

Nếu cần mua proxy cho kết nối tới các API được phép, anh em nên kiểm giao thức và cách thiết lập tunnel bằng một ca nhỏ. Khả năng kết nối của gateway cần được đánh giá riêng với cấu hình virtual host và pool của client; không hứa một tuyến mới sẽ tự sửa việc chọn sai origin trên hệ thống nguồn.

Lỗi 421 Misdirected Request và nghiệm thu bản sửa

Một bản sửa cần chỉ ra thành phần nào đã đổi: cấu hình virtual host, tên upstream, pool client hay quy tắc cân bằng tải. Giữ ca trước gây 421 và ca bình thường làm đối chứng. Nếu sửa một backend, kiểm các đích còn lại không bị lệch. Đừng nghiệm thu bằng việc chỉ gọi trang chủ nếu lỗi xuất hiện ở một API có origin hoặc listener khác; endpoint kiểm phải đại diện đúng tuyến đã gặp vấn đề.

Kiểm ba trạng thái riêng

Bộ kiểm nên có TLS hợp lệ và HTTP đúng origin, TLS hợp lệ nhưng request vào ngữ cảnh không phục vụ theo quy tắc fixture, cùng TLS sai tên. Ba trạng thái phải được log khác nhau: thành công, status 421 và lỗi xác minh trước HTTP. Nếu phần mềm biến tất cả thành timeout hoặc proxy error, nhóm vận hành sẽ khó chọn bước tiếp theo. Các trường hợp này cũng giúp kiểm giao diện báo lỗi có giữ thông tin cần thiết cho người dùng hay không.

Sau nâng client hoặc load balancer, chạy lại ca có thứ tự request và kết nối theo thiết kế. Một thay đổi về pool có thể ảnh hưởng hành vi dù URL và credential giữ nguyên. Ghi phiên bản cùng giao thức đã xác nhận trong hồ sơ kết quả. Không dùng kết luận của HTTP/1.1 để điền cột HTTP/2 hoặc HTTP/3 khi chưa chạy các giao thức đó; phần chưa kiểm cần được giữ rõ để người tiếp nhận biết phải bổ sung gì.

Bằng chứng gửi hỗ trợ

Hồ sơ cần có scheme, authority, cổng, SNI dự kiến, Host hoặc :authority thực, giao thức và chuỗi redirect nếu có. Thêm điểm phát status đã xác nhận hoặc ghi chưa biết, cùng request ID và thời điểm. Không đính private key, token hay toàn bộ cookie để mô tả lỗi định tuyến. Với chứng chỉ, thường chỉ cần các tên SAN và thông tin công khai phù hợp trong phạm vi hỗ trợ, cùng lỗi xác minh đã được che dữ liệu không liên quan.

Một ma trận gọn theo từng kết nối giúp người đọc thấy request nào dùng lại ngữ cảnh cũ và request nào mở mới. Tuy nhiên, nếu chưa có connection ID, đừng tự điền hai lượt vào cùng kết nối chỉ vì thời gian gần nhau. Ghi đúng mức quan sát và dùng công cụ có khả năng theo dõi khi cần bước sâu hơn. Kết luận kỹ thuật nên chỉ rộng bằng bằng chứng, nhất là với lỗi phụ thuộc nhiều lớp như origin, TLS và HTTP.

Cổng trong authority không nên bị bỏ quên

Khi so Host với SNI, fixture trong bài dùng tên host đơn giản trên listener lab. Hệ thống thật có thể có cổng không mặc định hoặc địa chỉ IPv6, nên cách tách bằng dấu hai chấm trong mẫu không phải bộ phân tích authority tổng quát. Nếu phát triển công cụ kiểm thật, dùng bộ phân tích URL phù hợp và giữ cổng như một phần dữ kiện. Một quy tắc so chuỗi đơn giản có thể làm công cụ báo sai với một authority hợp lệ nhưng khác cách biểu diễn.

SNI không mang cùng toàn bộ cấu trúc với URL, nên không ghép scheme hoặc cổng vào trường tên TLS một cách tùy tiện. Với client cấp cao, hostname từ URL thường là đầu vào cho các bước liên quan, còn các tùy chọn override cần được hiểu theo tài liệu. Khi phải kiểm một địa chỉ IP cụ thể, giữ tên origin bằng cơ chế kiểm tuyến của công cụ thay vì tự thay từng trường mà không nhìn thông điệp cuối. Mỗi phép override cần có mục tiêu và bằng chứng riêng.

Chứng chỉ nhiều tên không thay cấu hình ứng dụng

Một chứng chỉ hợp lệ cho hai tên chỉ giải quyết một phần xác minh danh tính TLS theo các điều kiện liên quan. Nó không tự tạo virtual host, route hoặc quyền phục vụ nội dung của cả hai tên ở backend. Nếu kết nối TLS thành công nhưng request nhận 421, kiểm bảng cấu hình origin và listener cùng phiên bản ứng dụng. Không cấp lại chứng chỉ ngay khi chưa thấy lỗi chain hoặc tên, vì nguyên nhân có thể nằm ở lớp xử lý sau bắt tay.

Ngược lại, một lỗi tên chứng chỉ cần được sửa trước khi đưa response HTTP vào kết luận. Nếu công cụ kiểm tắt xác minh, kết quả có thể cho thấy handler trả gì nhưng không đại diện client đang giữ kiểm TLS trong vận hành. Hồ sơ phải nói rõ chế độ kiểm; bài lab đã dùng CA file riêng để giữ điều kiện xác minh. Sự rõ ràng này giúp người khác tái hiện bằng cùng một mức kiểm, thay vì so hai lần chạy có nền tin cậy khác nhau.

Reverse proxy có thể dùng pool upstream riêng

Client ngoài cùng có thể mở kết nối mới mỗi lượt nhưng frontend vẫn tái sử dụng một kết nối phía upstream. Nếu lỗi phụ thuộc pool ở đoạn sau, thay cấu hình pool của client ngoài có thể không tạo khác biệt như anh em mong đợi. Cần sơ đồ hai kết nối và dữ kiện tại frontend để biết request nào dùng ngữ cảnh nào. Không kết luận đã loại trừ tái sử dụng chỉ từ việc công cụ client báo mở socket mới tới frontend.

Trong môi trường lab của tổ chức, có thể so cấu hình pool upstream theo phạm vi hẹp và kiểm log connection ID nếu sản phẩm hỗ trợ. Mỗi lần chỉ thay một tham số và giữ origin cùng payload. Nếu không có công cụ quan sát, ghi đây là giả thuyết cần nhóm quản lý frontend kiểm tiếp. Việc đưa ra một bước điều tra rõ thường hữu ích hơn việc yêu cầu người dùng đổi mạng nhiều lần mà không biết đoạn nào thực đã thay.

Đừng chuẩn hóa lỗi khác thành cùng một nhãn

Một pipeline có thể gặp lỗi DNS, TLS, 407 rồi 421 ở những lần chạy khác nhau. Nếu tầng xử lý chỉ trả proxy_failed, dữ liệu để điều tra bị mất. Nên giữ nhóm lỗi, status thực nếu có và giai đoạn đã hoàn thành trong kết quả nội bộ. Giao diện có thể trình bày ngắn, nhưng log hỗ trợ cần đủ để phân biệt. Khi sửa một nhánh, bộ hồi quy phải xác nhận các nhánh còn lại vẫn được phân loại đúng thay vì tất cả chuyển thành một thông báo chung mới.

Tên trong TLS, authority của request và cấu hình phục vụ cần được kiểm như ba dữ kiện có quan hệ, không gộp thành một địa chỉ.

Ma trận kiểm đúng origin

Anh em nên giữ request mẫu, kết quả đối chứng và cấu hình đã che thông tin nhạy cảm để kiểm lại sau thay đổi. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi triển khai, đánh giá đúng phạm vi của lỗi 421 Misdirected Request.