Telegram Desktop đã có một phương thức mới nguyên tắc để vượt tường lửa, phương thức này ngụy trang lưu lượng truy cập của ứng dụng nhắn tin thành việc truy cập trang web thông thường thông qua kết nối được bảo mật. Công nghệ thử nghiệm WEB-proxy được giới thiệu vào ngày 21 tháng 8 năm 2026, truyền dữ liệu MTProxy qua giao thức vận chuyển WebView dựa trên HTTPS hoặc WebSocket, khiến luồng dữ liệu không thể phân biệt với việc lướt web hợp pháp và mở ra một viễn cảnh mới để truy cập dịch vụ trong điều kiện bị hạn chế.
Cách hoạt động của đường hầm vô hình
Bản chất của sự đổi mới nằm ở việc sử dụng luồng ghép kênh, được định hướng qua trình duyệt nhúng trong ứng dụng. Máy khách vẫn giữ mã hóa và đóng khung quen thuộc của MTProxy, nhưng thay vì kết nối TCP trực tiếp, nó gửi tất cả dữ liệu qua một phiên WebView duy nhất. Định dạng khung đặc biệt OPEN, DATA, WINDOW và CLOSE cho phép đóng gói nhiều kết nối logic của Telegram vào một kênh được bảo mật, bên ngoài trông giống như tải trang web tiêu chuẩn.
Ở phía máy chủ, một bộ chuyển tiếp hoạt động, tiếp nhận luồng dữ liệu đơn nhất này và phân chia cẩn thận thành các kết nối riêng lẻ để truyền đến MTProxy tiêu chuẩn. Nút trung gian không giải mã nội dung và không biết địa chỉ đích cuối cùng, chỉ đóng vai trò là người chuyển phát mù. Tải trọng hữu ích vẫn không rõ ràng ở tất cả các giai đoạn sau khi biến đổi ban đầu từ ứng dụng, điều này đảm bảo tính bảo mật ngay cả khi đi qua các nút bổ sung.
Cuộc sống kép của tên miền
WEB-proxy hoạt động trên một tên miền HTTPS thông thường, tên miền này vẫn tiếp tục phục vụ một trang web công khai đầy đủ. Trang cầu nối để chuyển tiếp proxy chỉ được kích hoạt khi có tham số đặc biệt, được tính toán dựa trên cấu hình. Bất kỳ yêu cầu thông thường nào cũng nhận được trang chủ tiêu chuẩn của tài nguyên, tạo ra một bức màn che đáng tin cậy trước các hệ thống phát hiện tự động.
Việc lựa chọn phương thức truyền dữ liệu được cố định chặt chẽ trong trang trung gian được tạo ra cho mỗi phiên cụ thể. Bộ điều hợp cục bộ chuyển đổi các kết nối TCP thành các luồng logic và hợp nhất chúng trong khuôn khổ một phiên vận chuyển duy nhất, được liên kết với tên miền gốc. Kiến trúc như vậy cho phép sử dụng cơ sở hạ tầng của các dịch vụ lưu trữ thông thường và mạng phân phối nội dung mà không thu hút sự chú ý đến hoạt động proxy.
Chi tiết kỹ thuật triển khai
Tài liệu đầy đủ về triển khai và giao thức đã được công bố trong kho lưu trữ tproxy-server, nơi mô tả tất cả các chi tiết cấu hình. Người dùng chỉ định tên máy chủ chính tắc và bí mật MTProxy, từ đó sử dụng HMAC-SHA256 để suy ra một định danh duy nhất khả năng kết nối với cầu nối. Chỉ yêu cầu GET chính xác với tham số 43 ký tự cụ thể mới mở quyền truy cập vào trang đặc biệt, các lần truy cập khác được xử lý như những lượt truy cập thông thường.
Liên kết để kết nối có dạng https://t.me/webproxy?server=proxy.example.com&secret=... hoặc sử dụng lược đồ tg://webproxy. Cổng 443 và giao thức HTTPS là bắt buộc và cố định bởi thông số kỹ thuật của loại WEB-proxy. Giao thức được mô tả đảm bảo kiểu hóa yêu cầu nghiêm ngặt và loại trừ việc kích hoạt cầu nối một cách ngẫu nhiên.
Tình trạng hiện tại của dự án
Phát triển đang ở giai đoạn kiểm tra khái niệm và bao gồm triển khai phiên bản desktop, máy khách Android thử nghiệm và kế hoạch hỗ trợ iOS. Tất cả các nền tảng đều sử dụng trang trung gian, định dạng khung và thành phần máy chủ giống hệt nhau, giúp đơn giản hóa việc kiểm tra và phát triển sau này. Việc thống nhất phần máy khách và máy chủ cho phép thực hiện các thay đổi kịp thời và kiểm tra giả thuyết trên các hệ điều hành khác nhau.
Sự xuất hiện của WEB-proxy thể hiện sự chuyển đổi sang các phương pháp tinh vi hơn để tích hợp với cơ sở hạ tầng web hợp pháp. Việc sử dụng các cơ chế trình duyệt tiêu chuẩn và các giao thức được bảo mật làm phức tạp nhiệm vụ cho các hệ thống lọc, buộc chúng phải lựa chọn giữa việc chặn toàn bộ lưu lượng HTTPS hoặc duy trì khả năng truy cập của các dịch vụ thông thường. Giá trị thực tiễn của công nghệ sẽ được xác định bởi khả năng chống lại các phương pháp phân tích lưu lượng thích ứng và khả năng mở rộng mà không làm giảm hiệu suất.
Ý kiến của AI
Từ quan điểm phân tích dữ liệu của máy, sơ đồ WEB-proxy được trình bày về mặt cấu trúc lặp lại kỹ thuật ngụy trang lưu lượng truy cập thành HTTPS hợp pháp trước đó - "domain fronting", đã được phổ biến từ giữa những năm 2010 và được mô tả là một phương pháp che giấu địa chỉ đích thực của kết nối thông qua sự không khớp giữa SNI và HTTP Host. Theo thời gian, các nhà cung cấp CDN lớn đã hạn chế khả năng này ở cấp độ cơ sở hạ tầng, buộc các nhà phát triển phải tìm kiếm các con đường ngụy trang thay thế - trong trường hợp của Telegram, con đường đó là sử dụng trang bridge có tham số bên trong WebView. Tình huống này cho thấy sự tuần hoàn của cuộc chiến giữa kiểm duyệt và công nghệ vòng qua: mỗi giải pháp kỹ thuật có hiệu lực cho đến khi các hệ thống lọc thích ứng với mẫu lưu lượng mới. WEB-proxy có còn chống lại việc phân tích đặc điểm thời gian của gói tin và khối lượng phiên hay không, hay các nhà phát triển sẽ phải tìm kiếm một cấp độ ngụy trang mới một lần nữa?
end-content
