NanoClaw Telegram không phản hồi: polling, quyền và kiểm tra runtime

Khi bot Telegram NanoClaw ngừng phản hồi, bước đầu tiên không phải là sửa lỗi — mà là xác định xem tin nhắn đến có thực sự tới máy chủ hay không, vì hai lỗi NanoClaw được báo cáo riêng biệt tạo ra cùng khiếu nại đó với các dấu hiệu trái ngược. Trong một trường hợp, chiều đến chết trong khi gửi đi và tác vụ theo lịch vẫn hoạt động, nên mọi bề mặt mà người vận hành kiểm tra đều có vẻ khỏe mạnh. Trong trường hợp kia, cũng không gửi được gì, và log đánh dấu các tin nhắn đã gửi dù chúng chưa bao giờ được gửi. Cùng một khiếu nại, nguyên nhân khác nhau, và biện pháp cho trường hợp này không tác dụng với trường hợp kia.

Một điểm cần phân biệt trước mọi việc khác, vì kết quả tìm kiếm cụm từ này chủ yếu nói về một sản phẩm khác. OpenClaw là một dự án riêng và lớn hơn nhiều — 390.207 sao và giấy phép NOASSERTION khi bản ghi API kho lưu trữ được đọc vào ngày 21 tháng 9 năm 2026 — và chính trang chủ của NanoClaw định vị nó đối lập với dự án này. NanoClaw là nanocoai/nanoclaw: MIT, không bị lưu trữ, không phải fork, 30.818 sao, 1.068 issue mở, push gần nhất ngày 19 tháng 9 năm 2026 (GitHub API, cùng ngày). Địa chỉ qwibitai/nanoclaw cũ trả về 301 đến đó, nên đây là cùng một dự án được đổi tên chứ không phải dự án thứ hai. Hai dự án không dùng chung đường dẫn mã Telegram — NanoClaw cài adapter riêng bằng cách sao chép mã nguồn từ nhánh channels của nó (skill add-telegram) — vì vậy biện pháp của OpenClaw không áp dụng được. Để xem đầy đủ khác biệt, hãy xem NanoClaw so với OpenClaw.

Đọc dấu hiệu trước khi chạm vào bất cứ thứ gì

Mỗi hàng dưới đây là một lỗi riêng biệt, được báo cáo riêng, với một kiểm tra xác nhận riêng. Cả tám trường hợp đều được đọc vào ngày 21 tháng 9 năm 2026 từ trình theo dõi issue, các skill đã phát hành và tài liệu kênh của NanoClaw.

Chẩn đoán chính thức tuyến đầu của NanoClaw gồm hai tệp log cùng với ncl sessions list, ncl dropped-messages list và ncl wirings list. Không có phiên bản đã phát hành nào cung cấp lệnh kiểm tra trạng thái hoạt động của kênh, vì vậy việc phân loại dưới đây dựa vào các dòng log.

# 1. Is inbound polling failing, and for how long?
#    A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5

# 2. Did the Telegram adapter ever register this boot?
#    Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10

# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all   # Linux systemd installs

Tại sao mọi thứ có vẻ khỏe mạnh trong khi chiều đến đã chết

Đây là vấn đề mang tính cấu trúc, và cũng là phần làm lãng phí nhiều thời gian nhất. README của NanoClaw mô tả đường đi là ứng dụng nhắn tin đến router máy chủ, vào cơ sở dữ liệu inbound, vào container, ra cơ sở dữ liệu outbound, rồi quay lại qua bước delivery. Delivery tự polling cơ sở dữ liệu outbound, còn một vòng quét máy chủ 60 giây độc lập đánh thức các tin nhắn đến hạn và lặp lại. Inbound là giai đoạn duy nhất phụ thuộc vào poller Telegram — chính vì vậy người báo cáo issue #3728 thấy máy chủ vẫn hoạt động, delivery outbound tiếp tục chạy và tác vụ theo lịch tiếp tục được thực hiện trong khoảng bốn ngày hoàn toàn không có lưu lượng đến, với 11.178 lỗi liên tiếp được ghi nhận.

Hook sức khỏe lẽ ra phải phát hiện lỗi này nhưng lại không làm vậy. Tài liệu tham khảo interface adapter đã công bố của NanoClaw nói về isConnected() rằng nó "hiện không được máy chủ gọi bên ngoài các bài kiểm tra" và "bridge luôn trả về true". Trunk đã thay đổi kể từ đó: một lệnh ncl status báo cáo cờ kết nối theo từng adapter đã được đưa vào main ngày 15 tháng 9 năm 2026, sau bản phát hành v2.3.0, khiến tài liệu chính xác với mọi phiên bản đã phát hành nhưng lỗi thời với trunk. Hãy coi lệnh đó là nội bộ chưa phát hành chứ không phải lời khuyên — nó được đăng ký ở chế độ ẩn và chỉ dành cho máy chủ, đồng thời không xuất hiện trong tài liệu nào. Với Telegram, hai con đường dù sao cũng gặp nhau: cả adapter 4.29.0 lẫn 4.41.0 đều không triển khai isConnected (cả hai bản build dist đều được grep cho trang này), nên probe đều quay về true theo cả hai cách.

Tài liệu cũng có một khoảng trống tương ứng. Trang xử lý sự cố có một mục với tiêu đề "Webhook channel is silent" nhưng không có mục tương đương cho polling, còn hướng dẫn "Agent never replies" bắt đầu tại "Did the router accept it?" với ncl dropped-messages list — một bước vốn đã giả định rằng tin nhắn đã tới máy chủ. Khi poller chết, không có dòng tin nhắn bị loại bỏ nào để tìm, vì router chưa bao giờ thấy tin nhắn. Issue #2989 ghi nhận cùng ngõ cụt đó cho nguyên nhân riêng của nó: không có dòng log, không có dòng tin nhắn bị loại bỏ, không có gì để gỡ lỗi.

Không có phiên bản sửa lỗi, vì vậy hãy lập kế hoạch dựa trên điều đó

Issue #3728 vẫn mở với 0 bình luận, 0 nhãn và không có milestone, còn dấu thời gian cập nhật vẫn trùng với dấu thời gian tạo ngày 6 tháng 9 năm 2026. Bản phát hành mới nhất là v2.3.0 từ ngày 24 tháng 8 năm 2026, và commit duy nhất trên nhánh channels kể từ ngày 1 tháng 9 là bản sửa Mattermost. Trường hợp bộ lọc cũ cũng vậy: pull request sẽ ghim danh sách update rõ ràng đã mở trên channels từ ngày 22 tháng 8 năm 2026, và mã nguồn nhánh hiện tại hoàn toàn không chứa allowedUpdates. Khóa máy chủ một instance lẽ ra đã ngăn trường hợp máy chủ trùng lặp đã được đóng mà không merge. Vì vậy, cách diễn đạt trung thực là giảm thiểu rủi ro, không phải đưa ra một số phiên bản.

Có ba điều đáng biết trước khi bạn tự viết bản vá. Thứ nhất, chỉnh sửa cục bộ đối với src/channels/telegram.ts sẽ không tồn tại lâu: skill add-telegram sao chép tệp đó từ nhánh channels với hướng dẫn ghi đè vì nhánh này là chuẩn, còn skill update làm mới mọi kênh đã cài đặt — chính là lý do người báo cáo #3728 mất bản sửa sau mỗi lần cập nhật. Thứ hai, watchdog của người báo cáo cũng là một cảnh báo chứ không chỉ là công thức: phiên bản đầu tiên chỉ dùng bộ đếm đã gây ra một sự cố kéo dài ba ngày tồi tệ hơn, vì poller bị dừng thay vì thất bại, nên không ghi thêm lỗi nào và bộ đếm không bao giờ đạt ngưỡng. Phiên bản thứ hai dùng hai tín hiệu độc lập và không bao giờ để poller ở trạng thái dừng. Không điều nào trong số đó đã được phát hành, xác nhận hay kiểm chứng độc lập. Thứ ba, bất kể bạn xây dựng gì, hãy kiểm tra khả năng phục hồi theo cả hai hướng: gửi đi thành công không chứng minh được gì về chiều đến, vì vậy kiểm tra quan trọng là gửi một tin nhắn mới từ cuộc trò chuyện đã pairing và tạo ra một dòng inbound mới.

Lỗi kênh Telegram không phải vấn đề về model hay API

Đáng nói rõ điều này, vì lượt tìm kiếm tiếp theo theo trực giác thường đưa mọi người đi sai hướng. Tài liệu thông tin xác thực của NanoClaw cho biết các token kênh như TELEGRAM_BOT_TOKEN nằm trong .env và được tiến trình máy chủ sử dụng, không phải các container, trong khi thông tin xác thực model nằm trong vault và được tiêm vào các yêu cầu outbound trong lúc chạy. Tin nhắn inbound đến router và cơ sở dữ liệu inbound của session trước khi bất kỳ provider nào được chọn, vì provider được phân giải khi container khởi chạy (tài liệu agent providers). Không có base URL, key, gateway hay việc đổi provider nào có thể sửa vòng lặp polling bị chết, bộ lọc update cũ, xung đột poller, Group Privacy hay tuyến IPv6 bị hỏng.

Điểm giao thoa thực sự diễn ra theo chiều ngược lại. README của NanoClaw liệt kê Claude Code trong các yêu cầu, cụ thể cho /customize, /debug và mọi skill /add-channel, vì vậy việc sửa kênh cần nó trên máy chủ ngay cả khi các nhóm agent của bạn chạy trên hệ thống khác. Yêu cầu máy chủ là macOS hoặc Linux, Windows thông qua WSL2, Node.js 22 trở lên, pnpm 10 trở lên và Docker — đồng thời lưu ý rằng nanoclaw.dev vẫn quảng cáo Node.js 20 trở lên, trong khi README và changelog v2.3.0 đặt 22 làm mức tối thiểu bắt buộc. Hãy làm theo changelog, trong đó gọi việc nâng yêu cầu là breaking.

NanoClaw và kênh Telegram thực sự tốn bao nhiêu

Không có gói trả phí nào để mua nhằm thoát khỏi tình trạng bot không phản hồi; đó là thông tin hữu ích mà bảng này cho bạn biết. Chi phí chỉ bắt đầu phát sinh sau khi kênh hoạt động trở lại và tác nhân AI đang trả lời. Các con số dưới đây là phép tính token minh họa, không phải chi phí tác vụ được đo lường và không phải giới hạn hóa đơn: giả sử một cuộc trò chuyện được ghép nối có 25 lượt mỗi ngày, 20.000 token đầu vào không được lưu trong bộ nhớ đệm và 900 token đầu ra mỗi lượt, trong 30 ngày. Mức giá là giá hiện hành trong danh mục Kunavo cho mỗi triệu token.

Hãy nhân con số này theo lưu lượng của riêng bạn trước khi xem nó là ngân sách, đồng thời lưu ý giả định có ảnh hưởng lớn nhất: không có gì được cung cấp từ bộ nhớ đệm. Một phiên tác vụ kéo dài sẽ gửi lại ngữ cảnh, vì vậy hành vi bộ nhớ đệm làm thay đổi con số này nhiều hơn chênh lệch theo token giữa hai mô hình liền kề. Số tiền trong catalog của Kunavo là mức sàn thanh toán chứ không phải mức trần — khi bên upstream báo phí, hóa đơn là giá trị lớn hơn giữa chi phí trong catalog và chi phí upstream nhân với mức tăng giá áp dụng. Khoản nạp tối thiểu là $10 tín dụng trả trước, là mức tối thiểu để nạp tiền chứ không phải phí tác vụ hay gói đăng ký; xem chi tiết thanh toán.

Không lựa chọn nào trong bốn lựa chọn đó tác động đến đường dẫn Telegram. Để xem đầy đủ phần nhà cung cấp — hai biến môi trường mà thiết lập đọc, những gì container thực sự nhìn thấy, và vị trí của OpenCode cùng Codex — hãy xem Chi phí API và nhà cung cấp của NanoClaw. Nếu bạn đang kết nối runtime Claude mặc định với một endpoint tùy chỉnh, hướng dẫn tích hợp Claude Code và tài liệu tham khảo về URL cơ sở trình bày cấu hình; bạn có thể tạo tài khoản Kunavo khi sẵn sàng nạp tiền cho một khóa. Kunavo chưa kiểm thử NanoClaw ở runtime, và hướng dẫn thiết lập được công bố chỉ là tài liệu tham khảo cấu hình chứ không phải kiểm thử khả năng tương thích.

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

Đã kiểm tra ngày 21 tháng 9 năm 2026: bản ghi và danh sách bản phát hành của kho nanocoai/nanoclaw, trạng thái mở/đóng của các issue #2377, #2989, #3162, #3569 và #3728 cũng như các pull request #2225, #2697, #3449, #3460 và #3570, mã nguồn bộ điều hợp Telegram của nhánh channels, cả bản dựng bộ điều hợp 4.29.0 được ghim và bản dựng hiện tại 4.41.0 từ npm, tài liệu về kênh, thông tin xác thực, khắc phục sự cố và giao diện bộ điều hợp của NanoClaw, các kỹ năng add-telegram và debug, cùng trang Telegram Bot API. Không có nội dung nào trên trang này được thực thi trên một bản cài NanoClaw đang chạy. Mức giá token Kunavo lấy từ catalog trực tiếp, còn các con số đô la là phép tính token minh họa.