Cách Sửa Lỗi ERROR_TASK_NOT_SUPPORTED trong Các Lệnh Gọi API CAPTCHA

Tóm tắt nhanh

• 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ợ.
• Hãy xem chính xác task.type được gửi trên wire, không chỉ nhãn hiển thị trong cấu hình framework.
• Khớp loại CAPTCHA hiện tại (family + biến thể) với đúng task type trong tài liệu chính thức.
• Kiểu task trong REST, tên detection trong SDK và tên tool trong MCP thuộc các giao diện khác nhau, không thể dùng thay thế cho nhau.
• Hãy sửa yêu cầu không tương thích trước khi thử lại; gửi đi lặp lại cùng một request không làm cho task được hỗ trợ.

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 cho bạn biết điều gì

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.

Bước 1: Kiểm tra request đã được serialize

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.

Kiểm tra cấu trúc JSON một cách riêng biệt

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.

Bước 2: Khớp challenge hiện tại với task chính thức

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

Bước 3: Giữ riêng tên trong REST, SDK và MCP

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.

Bước 4: Sửa đúng một request trước khi chạy lại hàng đợi

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.

Cần gửi gì cho support nếu bạn nghĩ type đã đúng

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.

Xây dựng quy trình tự động ổn định với CapSolver

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.

Câu hỏi thường gặp

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.