🎉MỚICapSolver cho AI agent-Tích hợp MCP, công cụ agent và SDK
Anh Tuan
Data Science Expert
Đã xuất bản Oct 26, 2026
Đã cập nhật Oct 26, 2026 · đọc tối thiểu
ERROR_TASK_NOT_SUPPORTED nghĩa là kiểu CAPTCHA gửi lên không đúng hoặc không được dịch vụ hỗ trợ.task.type được gửi trên wire, không chỉ nhãn hiển thị trong cấu hình framework.Một tích hợp CAPTCHA có thể thất bại trước khi việc nhận dạng bắt đầu. API nhận request, kiểm tra loại task, rồi từ chối nếu đó là một thao tác không được hỗ trợ. Trong tình huống đó, thay đổi public key của site, chờ lâu hơn, hoặc tăng số lần retry có thể không đụng chạm gì đến vấn đề thực sự.
CapSolver mô tả riêng ERROR_TASK_NOT_SUPPORTED so với dữ liệu task không hợp lệ và việc nhận dạng thất bại. Hướng xử lý hữu ích là so sánh request mà ứng dụng của bạn thực sự gửi với hợp đồng cho dịch vụ và bề mặt tích hợp mà bạn đang dùng.
ERROR_TASK_NOT_SUPPORTED chỉ ra một vấn đề tương thích về loại task; nó không nói rằng ảnh CAPTCHA khó hay token trả về đã hết hạn.
Tài liệu mã lỗi chính thức định nghĩa điều kiện này là kiểu CAPTCHA không đúng hoặc không được hỗ trợ. Hãy giữ lại cả errorCode và errorDescription khi xem xét lỗi. Một thông báo chung chung kiểu “solver failed” sẽ làm mất đi chi tiết cần thiết để chọn cách sửa.
Bắt đầu với ba thông tin: endpoint nào nhận request, chuỗi type chính xác nào nó nhận được, và loại CAPTCHA nào xuất hiện trên trang. Đây là các phần tối thiểu cần có để so sánh việc triển khai với tài liệu.
Một tham số API là một phần của hợp đồng dịch vụ. Một cái tên “có vẻ hợp lý” không có nghĩa là được hỗ trợ. Viết hoa, chính tả, hậu tố và biến thể theo từng family phải lấy từ tài liệu tham chiếu, không phải từ mẫu đặt tên suy ra từ một nhà cung cấp khác.
Hãy kiểm tra request gửi ra sau khi SDK, lớp cấu hình, hoặc middleware đã biến đổi nó.
Màn hình thiết lập có thể hiển thị “reCAPTCHA v2”, trong khi JSON cuối cùng lại chứa một chuỗi khác. Một biến môi trường có thể vẫn giữ giá trị đã bị loại bỏ. Một wrapper có thể ánh xạ một tên thân thiện sang mã định danh task không còn khớp với dịch vụ mà nó gọi. Hãy đọc giá trị thực tế thay vì giả định cấu hình ban đầu đến API mà không đổi.
Với client chạy trong trình duyệt, Network panel của Chrome giải thích cách kiểm tra request và response. Với code phía server, hãy dùng log chẩn đoán phạm vi hẹp với các bí mật đã được loại bỏ. Tránh log API key, session cookie, token đầy đủ, hoặc dữ liệu form không liên quan.
Ghi lại method, host và path đích, loại task, tên trường, và mã cùng mô tả của response. Chỉ thêm task ID nếu dịch vụ thực sự trả về một cái. Lỗi ngay tại bước tạo task có thể khiến bạn không có mã định danh hợp lệ để poll.
Cú pháp JSON hợp lệ không chứng minh rằng task được hỗ trợ. Đặc tả JSON mô tả định dạng dữ liệu; tài liệu API định nghĩa ý nghĩa hợp lệ của các trường.
Sự phân biệt này hữu ích khi validator nói request well-formed nhưng API vẫn từ chối. Một chuỗi cú pháp đúng vẫn có thể chỉ định một thao tác không được hỗ trợ. Ngược lại, dữ liệu sai định dạng cần được chẩn đoán riêng thay vì bị coi là cùng một lỗi.
Hãy khớp family CAPTCHA và biến thể hiện tại trước khi chọn kiểu task thay thế.
Dùng tổng quan task type để tìm đúng family, sau đó mở tài liệu chi tiết của family đó. Ví dụ, tài liệu reCAPTCHA v2 liệt kê các tên task v2 được chấp nhận và các trường của chúng. Hãy copy mã định danh từ mục liên quan thay vì tự dựng từ trí nhớ.
Kiểm tra lại trang thực tế nếu ứng dụng vừa mới thay đổi tích hợp CAPTCHA. Một cấu hình cũ có thể mô tả nhà cung cấp hoặc biến thể trước đó. Chỉ dựa vào giao diện widget là không đủ để chứng minh task cũ vẫn áp dụng.
Cũng hãy kiểm tra ranh giới giữa task token và task nhận dạng. Một loại có thể trả về token cho luồng ứng dụng, trong khi loại khác trả lời một yêu cầu nhận dạng hình ảnh. Coi chúng có thể thay thế cho nhau chỉ vì cả hai đều là CAPTCHA có thể tạo ra request không đúng với hợp đồng.
Đừng thử nghiệm ngẫu nhiên các tên task cho đến khi một cái được chấp nhận. Việc đó làm mờ nguyên nhân ban đầu và có thể tạo ra một thao tác khác với thứ mà ứng dụng bạn thực sự cần.
Nhận mã thưởng CapSolver của bạn
Tăng ngân sách automation ngay lập tức!
Dùng mã thưởng CAP26 khi nạp tiền vào tài khoản CapSolver để nhận thêm 5% bonus cho mọi lần nạp — không giới hạn.
Đổi mã ngay trong Bảng điều khiển CapSolver
Giữ tên của mỗi bề mặt tích hợp trong đúng giao diện định nghĩa chúng.
Một request REST gửi một đối tượng task. Một SDK có thể cung cấp method và các giá trị detection đã chuẩn hóa. Một client MCP gọi các tool có tên riêng cùng schema input riêng. Tên do một lớp trả về không tự động là task.type hợp lệ ở lớp khác.
Ví dụ, tài liệu Core SDK giải thích các method trình duyệt và giải CAPTCHA của nó. Khi dùng SDK đó, hãy làm theo tham số được ghi trong tài liệu. Khi tự dựng request REST, hãy dùng tài liệu task REST. Khi dùng MCP, hãy kiểm tra schema của tool thay vì đặt tên tool vào trường task REST.
Điều này rất quan trọng khi migration. Thay package hoặc đổi API host có thể để lại các giá trị cấu hình cũ. Ngay cả những dịch vụ có envelope response tương tự cũng có thể hỗ trợ các mã định danh task và trường tùy chọn khác nhau. Hãy so sánh rõ ràng hợp đồng nguồn và đích.
Một tính năng không được hỗ trợ thì nên tiếp tục coi là không được hỗ trợ, cho đến khi nhà cung cấp công bố một đường đi chính thức. Đừng âm thầm thay bằng một family CAPTCHA khác chỉ để request vượt qua validation.
Hợp lệ hóa một request đã sửa trước khi để cùng cấu hình đó tới tất cả worker.
Trước hết, hãy dừng việc lặp tự động request không tương thích đã biết. Sau đó thay đổi phần không khớp mà bạn đã xác định và chạy một kiểm tra có phạm vi giới hạn. Xem lại status và các trường trả về trước khi bật lại workflow rộng hơn.
Hướng dẫn HTTP về retry các request không idempotent có liên quan khi lỗi mạng khiến kết quả của một thao tác không rõ ràng. Đừng cho rằng request tạo task mới là giống hệt với việc truy vấn kết quả của một task đã tồn tại. Lỗi tương thích và sự bất định về truyền tải cần cách xử lý khác nhau.
Nếu request đã sửa được chấp nhận, hãy tiếp tục theo flow response được ghi trong tài liệu cho task đó. Một số thao tác trả kết quả trực tiếp; số khác yêu cầu bước truy vấn kết quả. Đừng tự bịa task ID hay bắt đầu polling chỉ vì tích hợp trước đây của bạn luôn làm vậy.
Với các vấn đề do áp lực request lặp lại, hãy dùng tài liệu xử lý lỗi CAPTCHA API để xác định điều kiện thực tế được trả về. Kiểu không được hỗ trợ, giới hạn tần suất và lỗi tài khoản không phải là những nhãn khác nhau cho cùng một lỗi.
Hãy gửi một bản tái hiện gọn, đã che thông tin nhạy cảm, thể hiện rõ sự không khớp hợp đồng.
Bao gồm URL tài liệu bạn đã theo, task type chính xác, endpoint, phiên bản SDK hoặc wrapper nếu có dùng, cùng toàn bộ mã lỗi và mô tả. Thêm thời gian request với múi giờ và task ID nếu có.
Giải thích điều gì đã thay đổi: nâng cấp package, đổi nhà cung cấp, family CAPTCHA mới, hay thay đổi cấu hình triển khai. Điều này cho support một điểm khởi đầu hẹp hơn là cả log ứng dụng.
Đừng gửi bí mật tài khoản hay toàn bộ capture trình duyệt đã đăng nhập theo mặc định. Mục tiêu là thể hiện thao tác không được hỗ trợ và hình dạng request liên quan. Nếu cần thêm bằng chứng, hãy cung cấp qua kênh support phù hợp.
Tài liệu hướng dẫn lỗi unsolvable hiện có đề cập một giai đoạn khác: task đã được nhận dạng nhưng lần đó không tạo ra lời giải. Chỉ dùng nó khi đó là lỗi bạn nhận được.
Hãy sửa hợp đồng task trước, sau đó test một request có phạm vi giới hạn và kiểm tra kết quả. Tài liệu task hiện tại của CapSolver nên là nguồn cho các tên được chấp nhận và các trường bắt buộc. Giữ cho các tên này rõ ràng giúp việc migration và điều tra cùng support dễ xem xét hơn.
Hỏi: Retry có sửa được ERROR_TASK_NOT_SUPPORTED không?
Retry y nguyên không sửa được kiểu task không được hỗ trợ hoặc không chính xác. Hãy kiểm tra hợp đồng và request thực tế trước khi gửi lại.
Hỏi: Lỗi này có giống ERROR_CAPTCHA_UNSOLVABLE không?
Không. Lỗi task không được hỗ trợ liên quan đến loại request. Lỗi unsolvable liên quan đến một lần thử không nhận dạng được CAPTCHA. Hãy đọc chính xác response trước khi chọn cách sửa.
Hỏi: Tôi có thể dùng tên detection trong SDK làm task.type không?
Chỉ khi tài liệu REST ghi rõ giá trị đó. Nhãn detection, tên method trong SDK, và tên tool trong MCP là các khái niệm ở những giao diện khác nhau.
Hỏi: Tại sao lỗi xuất hiện sau khi đổi nhà cung cấp?
Việc đổi nhà cung cấp có thể để lại mã định danh task hoặc ánh xạ thuộc về dịch vụ cũ. Hãy so sánh request serialize cuối cùng với tài liệu hiện tại của nhà cung cấp đích.
Hỏi: Tôi có nên đổi sitekey trước không?
Không nhất thiết. Trước hết hãy xác định kiểu task có được hỗ trợ không. Sau đó kiểm tra các trường đặc thù cho family, gồm URL trang và sitekey, so với hợp đồng được ghi trong tài liệu.
Anh Tuan
Data Science Expert
Turning task outcomes into actionable insights.
GIỚI THIỆU TÁC GIẢ
Khắc phục lỗi ERROR_IP_BANNED bằng cách dừng các yêu cầu API CAPTCHA sai lặp lại, tìm lỗi đầu tiên, kiểm tra các mã liên quan và tiếp tục với một bài kiểm tra có kiểm soát.
So sánh nhận dạng hình ảnh CAPTCHA và giải token, hiểu rõ đầu vào và đầu ra của chúng, và chọn quy trình API phù hợp cho quy trình tự động hóa đã được bạn cho phép.
