SSL proxy là gì và nó hoạt động như thế nào?
Advanced Bot Mitigation Engineer
Những điểm chính:
- Một proxy SSL là một trung gian TLS, không phải là một công cụ bảo mật. Nó kết thúc mã hóa HTTPS để có thể đọc được lưu lượng truy cập mà nếu không có sẽ không thể nhìn thấy từ đầu đến cuối.
- Nó là một cuộc tấn công man-in-the-middle theo thiết kế — được xây dựng để kiểm soát tầm nhìn (kiểm tra, thực thi chính sách, DLP, gỡ lỗi), không phải để ẩn danh tính của bạn.
- Triển khai tới và lùi là hai triển khai đối nghịch. Tới bảo vệ lưu lượng truy cập ra ngoài từ các khách hàng nội bộ; lùi kết thúc TLS đến từ phía máy chủ của bạn.
- Quá trình bắt tay TLS là điều làm cho điều đó khả thi. Dù kết nối sử dụng RSA, Diffie-Hellman tạm thời, hay TLS 1.3, proxy tham gia vào quá trình bắt tay để đạt được văn bản gốc.
- Bẻ gãy mã hóa đầu đến đầu là một sự đánh đổi. Bạn có được kiểm tra và kiểm soát, nhưng proxy trở thành một mục tiêu có giá trị cao và gánh vác gánh nặng về lòng tin, quyền riêng tư và tuân thủ.
- Nó khác với proxy SOCKS hoặc HTTP thông thường, vì nó hiểu và xử lý đặc biệt lớp TLS thay vì chỉ đơn giản là truyền tải byte.
- Để thu thập dữ liệu, bạn thường không chạy của riêng mình — định tuyến thông qua cơ sở hạ tầng proxy cư dân quản lý cung cấp cho mục tiêu một kết nối sạch, được mã hóa mà không có lớp kết thúc TLS của riêng bạn.
- Miễn phí để bắt đầu. Các tài khoản mới Scrapeless bao gồm thời gian chạy Scraping Browser miễn phí và truy cập proxy cư dân — đăng ký tại trang web Scrapeless.
Giới thiệu: proxy đọc mã hóa
Hầu hết mọi lưu lượng web hiện nay đều di chuyển qua HTTPS, được mã hóa trong quá trình truyền tải. Điều này tốt cho tính bảo mật, nhưng cũng tạo ra một điểm mù: một tường lửa chỉ có thể nhìn thấy các byte được mã hóa không thể xác định liệu một nhân viên đang tải lên một tệp nhạy cảm đến một dịch vụ không được phê duyệt, liệu một tải xuống có chứa malware hay không, hoặc liệu một ứng dụng có đang rò rỉ dữ liệu mà nó không nên. Mã hóa bảo vệ payload khỏi mọi người ở giữa — bao gồm cả những người chịu trách nhiệm về mạng.
Một proxy SSL tồn tại để giải quyết căng thẳng đó. Thay vì truyền lưu lượng được mã hóa qua mà không bị chạm vào, nó cố ý định vị bản thân như là một điểm cuối của kết nối TLS để có thể giải mã, kiểm tra và mã hóa lại những gì đi qua. Các nhóm an ninh sử dụng nó để thực thi chính sách sử dụng hợp lý và ngăn ngừa mất dữ liệu; các nhóm vận hành sử dụng nó ở phía máy chủ để tập trung chứng nhận và giảm tải công việc mã hóa; các nhà phát triển sử dụng một phiên bản cục bộ của cùng một ý tưởng để gỡ lỗi lưu lượng API.
Hướng dẫn này định nghĩa chính xác một proxy SSL, đi qua quá trình bắt tay TLS cho phép nó hoạt động, phân biệt giữa các triển khai tới và lùi, và thành thật về sự đánh đổi bảo mật mà nó đại diện. Nó kết thúc với nơi mà cơ sở hạ tầng proxy quản lý phù hợp khi mục tiêu là thu thập dữ liệu đáng tin cậy hơn là tự mình vận hành một cánh cổng kiểm tra. Để có bối cảnh liền kề, xem các giải thích của chúng tôi về proxy đám mây là gì và VPS so với proxy.
Proxy SSL là gì?
Một proxy SSL là một máy chủ trung gian kết thúc và khởi động lại kết nối TLS (Transport Layer Security) giữa hai bên, để lưu lượng HTTPS nếu không sẽ được mã hóa đầu đến cuối có thể đọc được bởi proxy. Bởi vì nó chia một kết nối an toàn thành hai — client-to-proxy và proxy-to-origin — nó có thể giải mã lưu lượng ở một bên, kiểm tra hoặc sửa đổi nó, và mã hóa lại ở bên kia.
Một lưu ý nhanh về tên gọi. SSL (Secure Sockets Layer) là giao thức ban đầu; nó đã được thay thế bằng TLS, nhưng tên cũ vẫn tồn tại. Trong thực tế, "quá trình bắt tay SSL" và "quá trình bắt tay TLS", và "proxy SSL" và "proxy TLS," được sử dụng thay thế cho nhau. Lưu lượng mà một proxy SSL xử lý ngày nay hầu như luôn là TLS.
Đặc điểm định nghĩa là điều đáng nói một cách trực tiếp: một proxy SSL là một man-in-the-middle TLS theo thiết kế. Một proxy tiêu chuẩn chỉ đơn giản chuyển tiếp byte mã hóa không bao giờ thấy văn bản gốc. Một proxy SSL cố ý chèn bản thân như một điểm cuối TLS chính xác để có thể làm như vậy. Khả năng đó là điều làm cho nó có giá trị cho việc kiểm tra và kiểm soát — và nó cũng là điều làm cho nó trở thành thứ bạn triển khai một cách có chủ đích và quản lý cẩn thận, không phải là một công cụ mà bạn tìm kiếm để đạt được sự riêng tư.
Tại Scrapeless, chúng tôi chỉ truy cập dữ liệu công khai có sẵn trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách quyền riêng tư của trang web áp dụng. Nội dung trong bài viết này chỉ nhằm mục đích minh họa.
Cách một proxy SSL hoạt động
Để hiểu về proxy, trước hết bạn phải hiểu về quá trình bắt tay mà nó tham gia vào. Theo bài giải thích của Cloudflare "Điều gì xảy ra trong một quá trình bắt tay TLS", quá trình bắt tay TLS diễn ra sau khi kết nối TCP được thiết lập, mỗi khi HTTPS được sử dụng. Mục tiêu của nó là thống nhất về một phiên bản TLS, chọn một bộ mã hóa (tập hợp các thuật toán mật mã đã được đồng ý), xác thực máy chủ qua chứng chỉ của nó và tổ chức cấp chứng chỉ (CA) mà nó ký, và tạo ra khóa phiên đối xứng sẽ mã hóa phần còn lại của cuộc trao đổi.
Một proxy SSL tham gia vào quá trình này thay vì chỉ đơn thuần chuyển tiếp nó. Các bước chính xác phụ thuộc vào phương pháp trao đổi khóa đang được sử dụng.
Quá trình bắt tay RSA (cổ điển, không còn được xem là an toàn)
Trong quá trình trao đổi dựa trên RSA cũ, máy khách mở đầu với một client hello mang theo phiên bản TLS mà nó hỗ trợ, các bộ mã hóa, và một client random. Máy chủ trả lời bằng một server hello chứa chứng chỉ của nó, bộ mã hóa đã chọn, và một server random. Máy khách xác thực chứng chỉ so với CA phát hành, tạo ra một premaster secret, mã hóa nó bằng khóa công khai của máy chủ, và gửi đi; máy chủ giải mã nó bằng khóa riêng của mình. Cả hai bên sau đó tạo ra các khóa phiên từ hai giá trị ngẫu nhiên cộng với premaster secret, trao đổi các tin nhắn Finished đã được mã hóa, và bắt đầu mã hóa đối xứng.
Kế hoạch này không còn được xem là an toàn, chủ yếu vì nó thiếu tính bảo mật tiến về phía trước: bất kỳ ai sau này có được khóa riêng của máy chủ đều có thể giải mã các phiên đã qua.
Quá trình bắt tay Diffie-Hellman tạm thời
Biến thể Diffie-Hellman theo hình thức tương tự nhưng khắc phục được lỗ hổng đó. Máy chủ bổ sung gửi một chữ ký số trên các tin nhắn bắt tay, và thay vì máy khách mã hóa một premaster secret, cả hai bên trao đổi các tham số Diffie-Hellman và mỗi bên tính toán premaster secret một cách độc lập. Bởi vì bí mật không bao giờ được truyền đi, việc ghi lại lưu lượng và khóa của máy chủ sau đó sẽ không tiết lộ nó — điều này là bảo mật tiến về phía trước. Các khóa phiên sau đó được tạo ra từ premaster secret và hai giá trị ngẫu nhiên, như trước đó.
Quá trình bắt tay TLS 1.3
TLS 1.3, được chuẩn hóa trong RFC 8446, loại bỏ hoàn toàn việc trao đổi khóa RSA và các bộ mã hóa không an toàn cũ và tinh giản phần còn lại:
- client hello đã bao gồm các tham số trao đổi khóa, giả định phương pháp ưu tiên của máy chủ.
- Do đó, máy chủ có thể ngay lập tức tính toán bí mật chính và trả lời bằng server hello của nó, chứng chỉ, chữ ký, server random, và Finished chỉ trong một lượt đi.
- Máy khách xác thực, tạo ra cùng một bí mật chính, và gửi Finished của riêng mình.
Kết quả là một quá trình bắt tay nhanh hơn — chỉ một lượt đi thay vì hai. TLS 1.3 cũng định nghĩa 0-RTT hồi phục: một máy khách quay lại mà nắm giữ một "bí mật chính hồi phục" và một vé phiên từ một kết nối trước đó có thể gửi dữ liệu ứng dụng đã được mã hóa trong tin nhắn đầu tiên của nó, mà không cần lượt đi nào cả.
Vị trí của proxy trong tất cả những điều này
Để một proxy SSL có thể đọc dữ liệu thô, nó không thể quan sát thụ động bất kỳ quá trình bắt tay nào trong số này — mật mã được thiết kế cụ thể để ngăn điều đó. Thay vào đó, nó hoàn thành một quá trình bắt tay ở mỗi bên: nó trình bày một chứng chỉ cho máy khách và đàm phán một phiên, và nó hoạt động như một máy khách đối với nguồn gốc và đàm phán một phiên thứ hai. Nắm giữ cả hai bộ khóa phiên, nó giải mã lưu lượng khi nó đến trên một kết nối và mã hóa lại trước khi rời đi trên kết nối kia. Dữ liệu thô tồn tại, tạm thời, bên trong proxy — đó là toàn bộ cơ chế, và toàn bộ sự đánh đổi.
Proxy SSL Xuôi vs Proxy SSL Ngược
Cơ chế giải mã-kiểm tra-mã hóa lại tương tự được triển khai theo hai hướng ngược nhau, và sự phân biệt này quan trọng cho ai tin tưởng vào điều gì.
Một proxy SSL xuôi ngồi ở phía máy khách, giữa người dùng nội bộ của một tổ chức và internet. Nó chặn các kết nối TLS ra ngoài, trình bày chứng chỉ của riêng mình cho máy khách nội bộ, và dựa vào những máy khách này tin tưởng vào một CA được quản lý nội bộ để sự thay thế được chấp nhận. Sau đó, nó giải mã, kiểm tra hoặc lọc lưu lượng, và mã hóa lại để đến nguồn gốc thực. Triển khai điển hình là tính năng SSL-Bump của Squid, hoạt động thông qua một quy trình peek/splice/bump để quyết định từng kết nối liệu có kiểm tra hay cho phép lưu lượng đi qua. Các proxy xuôi là động cơ đứng sau việc ngăn ngừa mất dữ liệu ra ngoài, lọc phần mềm độc hại và URL, và thực thi việc sử dụng hợp lệ.
Một proxy SSL ngược nằm ở phía máy chủ, trước các máy chủ gốc của bạn. Nó kết thúc TLS của khách hàng đến tại rìa — kết thúc TLS — và tùy chọn mã hóa lại cho các máy chủ phía sau nó. Bởi vì nó sở hữu chứng chỉ công khai, nó tập trung quản lý chứng chỉ, chuyển tải công việc mã hóa ra khỏi các máy chủ ứng dụng, và cung cấp cho bạn một điểm duy nhất để áp dụng Tường lửa Ứng dụng Web (WAF), kiểm tra, và cân bằng tải trước khi lưu lượng truy cập đến được ứng dụng.
| Kích thước | Proxy SSL Xuôi | Proxy SSL Ngược |
|---|---|---|
| Vị trí | Giữa các khách hàng nội bộ và internet | Trước các máy chủ gốc của bạn |
| Bảo vệ | Lưu lượng ra / tổ chức | Lưu lượng vào / ứng dụng |
| Chứng chỉ của ai | Chứng chỉ của proxy thông qua CA nội bộ mà các khách hàng tin cậy | Chứng chỉ công khai cho trang web được bảo vệ |
| Công việc điển hình | DLP, malware và lọc URL, chính sách sử dụng hợp lệ | Kết thúc TLS, WAF, cân bằng tải, chuyển giao mã hóa |
| Ai điều hành nó | Tổ chức phía khách hàng | Chủ sở hữu trang web hoặc dịch vụ |
| Cơ chế tham chiếu | Squid SSL-Bump (peek / splice / bump) | Kết thúc TLS tại một bộ cân bằng tải hoặc cổng |
Một cách ngắn gọn hữu ích: một proxy xuôi trả lời "cái gì đang rời khỏi mạng của tôi?" và một proxy ngược trả lời "cái gì đang đến các máy chủ của tôi?"
Mã hóa, Kiểm tra & An ninh
Thật dễ dàng để phân loại bất kỳ proxy nào dưới "an toàn hơn", nhưng một proxy SSL đáng được xem xét cẩn thận hơn. Những gì nó thực sự mang lại là khả năng nhìn thấy có kiểm soát, và điều này có một cái giá.
Về mặt lợi ích, proxy giữ lại các thuộc tính cốt lõi mà TLS cung cấp và thêm một thuộc tính mới. Có tính bảo mật, vì mỗi phần của kết nối vẫn được mã hóa trong quá trình truyền; xác thực, vì các chứng chỉ được xác thực trong mỗi lần bắt tay; và khả năng nhìn thấy và kiểm soát — lý do tồn tại của nó — cho phép các công cụ an ninh quét lưu lượng đã được giải mã để tìm kiếm mối đe dọa, rò rỉ và vi phạm chính sách. Mặt khác cũng có hiệu suất: kết thúc TLS tại rìa giảm tải công việc mã hóa từ các máy chủ ứng dụng và cho phép lưu trữ gần với các khách hàng.
Tuy nhiên, cách trình bày trung thực là sự đánh đổi. Bằng cách kết thúc TLS, proxy cố ý phá vỡ mã hóa đầu cuối. Dữ liệu gốc bị lộ ra bên trong proxy, điều này có nghĩa là:
- Proxy trở thành mục tiêu giá trị cao. Nó giữ các khóa và thấy lưu lượng đã được giải mã cho mọi người đứng phía sau nó. Việc xâm phạm nó sẽ làm tổn hại nhiều hơn một kết nối đơn lẻ.
- Nó tạo ra gánh nặng về lòng tin và quyền riêng tư. Ở phía xuôi, lưu lượng được mã hóa của người dùng đang bị đọc; việc này phải được công bố, xác định phạm vi và quản lý. Việc kiểm tra lưu lượng chứa dữ liệu cá nhân, tài chính hoặc sức khỏe đi kèm với các nghĩa vụ rõ ràng về quyền riêng tư và tuân thủ.
- Cấu hình sai làm suy yếu chính điều mà TLS bảo vệ. Việc xác thực chứng chỉ lỏng lẻo ở phần gốc, hoặc lựa chọn mã hóa yếu có thể làm giảm an toàn một cách lén lút cho mọi kết nối mà proxy xử lý.
Đó là lý do tại sao hướng dẫn phù hợp với tiêu chuẩn, chẳng hạn như khuyến nghị bảo vệ tầng truyền tải của OWASP, coi việc kiểm tra TLS là một khả năng cần triển khai một cách thận trọng: xác thực chứng chỉ nghiêm ngặt cho mỗi phần, ưu tiên các phiên bản giao thức hiện đại và bộ mã hóa bảo mật, hạn chế những gì bị giải mã, và bảo vệ chính proxy như hạ tầng quan trọng. Một proxy SSL là bề mặt kiểm soát cho một tổ chức sở hữu cả hai đầu của mối quan hệ tin cậy — không phải là cách để một cá nhân có được quyền riêng tư.
Nhận khóa API của bạn trên kế hoạch miễn phí: Trang web Scrapeless
Các Trường Hợp Sử Dụng
Khả năng giải mã và kiểm tra xuất hiện trong một số vai trò:
- Cổng bảo mật ra của doanh nghiệp (xuôi). Thực thi chính sách sử dụng hợp lệ, chặn malware và URL rủi ro, và thực hiện phòng ngừa mất dữ liệu trên HTTPS đầu ra.
- Cổng rìa kết thúc TLS, cân bằng tải, hoặc WAF (ngược). Tập trung chứng chỉ, chuyển tải công việc mã hóa, và lọc lưu lượng vào bằng WAF trước khi nó đến ứng dụng.
- Cổng API. Kết thúc TLS, xác thực người gọi, và áp dụng chính sách định tuyến hoặc giới hạn tốc độ ở một ranh giới được quản lý duy nhất.
- Gỡ lỗi lưu lượng trong phát triển. Kỹ sư chạy một proxy chặn cục bộ để đọc các yêu cầu và phản hồi HTTPS của riêng họ trong khi xây dựng và kiểm tra một tích hợp.
- Thu thập dữ liệu qua HTTPS. Định tuyến lưu lượng scraper qua hạ tầng proxy để mục tiêu thấy một kết nối sạch, được mã hóa từ một IP dân cư — xử lý TLS đến đích thay mặt cho người yêu cầu.
Proxy SSL so với Các Loại Proxy Khác
Một proxy SSL được định nghĩa bởi lớp mà nó hoạt động. So sánh nó với các loại proxy láng giềng làm sáng tỏ điều gì là khác biệt về nó.
| Loại proxy | Lớp mà nó hoạt động | Thấy văn bản rõ của HTTPS? | Sử dụng điển hình |
|---|---|---|---|
| Proxy SSL / TLS | Lớp phiên TLS | Có — kết thúc TLS theo thiết kế | Kiểm tra, DLP, kết thúc TLS, gỡ lỗi |
| Proxy HTTP | Ứng dụng (HTTP) | Chỉ dành cho HTTP không mã hóa; tunneled HTTPS ẩn danh qua CONNECT | Lưu cache, lọc cơ bản, định tuyến yêu cầu |
| Proxy SOCKS | Dưới lớp ứng dụng | Không — chuyển tiếp byte thô, không phụ thuộc giao thức | Tunneling TCP/UDP tổng quát, hỗ trợ nhiều giao thức |
| Proxy trong suốt | Mạng / ứng dụng | Chỉ nếu nó cũng thực hiện việc chặn TLS | Định tuyến bắt buộc mà không cần cấu hình từ phía máy khách |
Sự tương phản chính: Một proxy SOCKS cố tình không biết những gì nó chuyển tải — nó chuyển byte mà không hiểu TLS. Một proxy HTTP đơn giản có thể đọc HTTP không mã hóa nhưng, khi đối mặt với HTTPS, chỉ đơn giản mở một đường hầm và chuyển tiếp luồng mã hóa mà không chạm vào. Một proxy SSL là loại duy nhất hiểu và xử lý lớp TLS để hành động dựa trên nội dung bên trong.
Cách Scrapeless Hoạt Động
Khi mục tiêu là thu thập dữ liệu đáng tin cậy hơn là vận hành một cổng kiểm tra, bạn thường không muốn tự đứng lên và quản lý proxy SSL hoặc lớp kết thúc TLS của riêng mình. Scrapeless cung cấp proxy住宅 tại hơn 195 quốc gia và một trình duyệt đám mây chống phát hiện — Scrapeless Scraping Browser — xử lý HTTPS và trao đổi TLS đến các mục tiêu của bạn ở nội bộ. Bạn định tuyến yêu cầu qua Scrapeless và điểm đến thấy một kết nối sạch, mã hóa xuất phát từ một IP住宅, với trình duyệt đám mây render JavaScript và quản lý dấu vân tay ở phía đám mây.
Ranh giới cần được xác định chính xác: Scrapeless không phải là một proxy kiểm tra SSL, và nó không phải là công cụ để đọc lưu lượng mã hóa của người khác. Đây là hạ tầng proxy và trình duyệt được quản lý xử lý công việc vận chuyển và render để bạn không tự vận hành lớp đó. Khám phá sản phẩm proxy và giải pháp proxy rộng hơn, xem xét các gói trên trang giá cả, và tìm thông tin tích hợp trong tài liệu.
Kết luận
Một proxy SSL làm những gì một proxy bình thường không thể: nó đọc bên trong HTTPS, bằng cách kết thúc TLS ở mỗi bên, giữ cả hai tập hợp khóa phiên, và giải mã lưu lượng để có thể được kiểm tra và mã hóa lại. Triển khai về phía trước, nó giám sát những gì rời khỏi một mạng; triển khai ngược lại, nó kết thúc và sàng lọc những gì đến một máy chủ. Dù theo cách nào, nó cũng là một man-in-the-middle theo thiết kế, và khả năng nhìn thấy mà nó cung cấp phải trả giá bằng sự tin tưởng, quyền riêng tư và gánh nặng tuân thủ cần được quản lý. Hãy cân nhắc khi bạn sở hữu cả hai đầu của một mối quan hệ tin cậy và cần kiểm soát tầm nhìn — kiểm tra, DLP, kết thúc TLS ở rìa — và khi mục tiêu đơn giản là thu thập dữ liệu web công khai một cách đáng tin cậy qua các kết nối mã hóa,住宅, hãy định tuyến qua hạ tầng được quản lý thay thế. Để biết thêm thông tin liên quan, xem proxy đám mây là gì và VPS và proxy.
Câu hỏi thường gặp
Proxy SSL có giống như proxy HTTPS không?
Các thuật ngữ này có sự trùng lặp và thường được sử dụng thay thế cho nhau, vì cả hai đều xử lý lưu lượng được bảo mật bằng TLS. Sự phân biệt ý nghĩa là liệu proxy thực sự kết thúc TLS để đọc văn bản gốc (can thiệp TLS/SSL thật sự) hay chỉ mở một đường hầm mã hóa và chuyển tiếp byte HTTPS mà không giải mã chúng (proxy HTTP đơn giản đang tiến hành tunneling CONNECT). Khi mọi người nói "proxy SSL", họ thường có ý nghĩa là cái trước.
Có phải proxy SSL giải mã lưu lượng của tôi không?
Có — đó là toàn bộ mục đích. Một proxy SSL kết thúc TLS để có thể giải mã, kiểm tra và mã hóa lại lưu lượng đi qua nó. Nếu một proxy không giải mã, nó không hoạt động như một proxy SSL. Đây là lý do tại sao nó nên được coi là một kiểm soát có mục đích, được quản lý, không phải là một tính năng riêng tư.
Proxy trực tiếp và proxy ngược — tôi cần cái nào?
Quyết định dựa trên những gì bạn đang bảo vệ. Chọn proxy SSL trực tiếp để kiểm tra và kiểm soát lưu lượng ra từ người dùng của chính bạn (DLP, lọc URL và phần mềm độc hại, chính sách). Chọn proxy SSL ngược để kết thúc TLS đến từ phía máy chủ của bạn (quản lý chứng chỉ, WAF, cân bằng tải, chuyển giao mã hóa).
Sử dụng proxy SSL có hợp pháp không?
Vận hành một trên hạ tầng và lưu lượng mà bạn sở hữu hoặc quản lý là thực tế tiêu chuẩn, miễn là nó được công khai và cấu hình phù hợp với các nghĩa vụ quyền riêng tư hiện hành. Chặn lưu lượng mà bạn không có thẩm quyền cũng là một vấn đề khác. Hạn chế nó đến các hệ thống bạn kiểm soát, công khai cho những người lưu lượng của họ bị kiểm tra, và tham khảo ý kiến luật sư cho khu vực của bạn.
Proxy SSL có mang lại cho tôi sự ẩn danh hoặc quyền riêng tư không?
Không. Nó được xây dựng để có thể nhìn thấy vào lưu lượng mã hóa, không phải để ẩn giấu nó, vì vậy đối với lưu lượng chảy qua nó, quyền riêng tư sẽ giảm thay vì tăng lên. Sự ẩn danh đối với yêu cầu ra là một mối quan tâm riêng, được xử lý bởi IP nguồn của proxy và định tuyến thay vì bị can thiệp TLS.
Tôi có phải tự vận hành proxy SSL của mình để thu thập dữ liệu web không?
Không. Để thu thập dữ liệu, con đường thực tiễn là chuyển các yêu cầu qua hạ tầng proxy dân cư được quản lý, xử lý HTTPS và TLS đến mục tiêu thay cho bạn, để bạn tránh phải vận hành và bảo mật một lớp chấm dứt TLS cho riêng mình.
Sẵn sàng Xây Dựng Dòng Dữ Liệu AI của Bạn?
Tham gia cộng đồng của chúng tôi để nhận kế hoạch miễn phí và kết nối với các nhà phát triển đang xây dựng các quy trình thu thập dữ liệu dựa trên proxy: Discord · Telegram.
Đăng ký tại trang web Scrapeless để nhận quyền truy cập miễn phí vào trình duyệt thu thập dữ liệu và proxy dân cư, và chuyển các yêu cầu HTTPS mà quy trình của bạn cần thông qua hạ tầng được quản lý thay vì lớp SSL-proxy riêng của bạn.
Tại Scrapless, chúng tôi chỉ truy cập dữ liệu có sẵn công khai trong khi tuân thủ nghiêm ngặt các luật, quy định và chính sách bảo mật trang web hiện hành. Nội dung trong blog này chỉ nhằm mục đích trình diễn và không liên quan đến bất kỳ hoạt động bất hợp pháp hoặc vi phạm nào. Chúng tôi không đảm bảo và từ chối mọi trách nhiệm đối với việc sử dụng thông tin từ blog này hoặc các liên kết của bên thứ ba. Trước khi tham gia vào bất kỳ hoạt động cạo nào, hãy tham khảo ý kiến cố vấn pháp lý của bạn và xem xét các điều khoản dịch vụ của trang web mục tiêu hoặc có được các quyền cần thiết.
