Lỗi thường gặp khi dùng webhook TradingView

Khi bot không chạy như mong đợi, cảm giác đầu tiên là mọi thứ đều có thể là nguyên nhân. Bài viết này chia lỗi thành bảy nhóm theo vị trí trong chuỗi, để bạn khoanh vùng nhanh thay vì sửa thử ngẫu nhiên.

Cách tiếp cận lỗi theo tầng

Một hệ thống webhook là một chuỗi gồm sáu mắt: TradingView phát điều kiện, TradingView gửi webhook, đường truyền tới server, server nhận và xác thực, server ra quyết định, và sàn thực thi. Lỗi luôn nằm ở một mắt nào đó.

Nguyên tắc gỡ lỗi hiệu quả là kiểm tra theo thứ tự từ đầu chuỗi tới cuối, và không nhảy bước. Nếu bạn nghi lỗi ở phía sàn nhưng chưa xác nhận alert có bắn hay không, bạn đang đoán.

Ba câu hỏi theo thứ tự sẽ khoanh vùng được hầu hết sự cố. Thứ nhất, alert có bắn không. Thứ hai, server có nhận được không. Thứ ba, nội dung nhận được có đúng như bạn soạn không. Chỉ khi cả ba câu trả lời là có mà bot vẫn không đặt lệnh, vấn đề mới nằm ở phần thực thi.

Bảng tra nhanh theo hiện tượng

Hiện tượng	Nhóm lỗi	Kiểm tra đầu tiên
Không thấy thông báo nào	alert không bắn	điều kiện có xảy ra không
Alert có bắn nhưng server im	không tới được endpoint	gọi thử endpoint từ ngoài
Server báo lỗi dữ liệu	nội dung sai định dạng	in nội dung thô
Lệnh bị từ chối	ràng buộc của sàn	khối lượng, giá, số dư
Khối lượng sai	logic tính toán	bước khối lượng, làm tròn
Nhiều lệnh cho một tín hiệu	trùng lặp	chế độ kiểm tra và mã tín hiệu
Không có lệnh nào dù mọi thứ đúng	lỗi im lặng	nhịp tim và log

Nhóm 1: alert không bắn

Đây là nhóm lỗi bị chẩn đoán sai nhiều nhất, vì người dùng thường nghĩ ngay tới webhook trong khi vấn đề nằm ở điều kiện.

Cách kiểm tra chắc chắn nhất là hiển thị tín hiệu trực tiếp trên chart. Hãy vẽ một nhãn hoặc một hình tại đúng vị trí bạn gọi alert. Nếu nhãn không bao giờ xuất hiện, điều kiện chưa từng đúng và mọi thứ phía sau đều vô nghĩa.

Ba nguyên nhân tiếp theo thường gặp. Một là alert được tạo từ sai script, khi trên chart có nhiều chỉ báo cùng chạy. Hai là alert đã bị tắt do hết hạn hoặc do bạn đã chạm hạn mức số alert của gói. Ba là alert được tạo trên sai cặp hoặc sai khung thời gian so với thiết kế chiến lược.

Một nguyên nhân ít được nghĩ tới là gói tài khoản hết hạn. Khi gói hết hạn, webhook không còn được gửi, và bot của bạn im lặng chứ không báo lỗi.

Nhóm 2: alert bắn nhưng server không nhận

Nếu bạn đã xác nhận alert bắn, bước tiếp theo là kiểm tra đường tới server.

Bốn nguyên nhân phổ biến. Thứ nhất, địa chỉ webhook dùng giao thức không bảo mật nên TradingView từ chối gửi. Thứ hai, tên miền hoặc chứng chỉ có vấn đề, ví dụ chứng chỉ hết hạn hoặc tên miền không trỏ đúng địa chỉ máy chủ. Thứ ba, tường lửa hoặc nhóm bảo mật của nhà cung cấp chặn cổng bạn đang dùng. Thứ tư, ứng dụng của bạn chỉ lắng nghe trên địa chỉ nội bộ, nên request từ internet không vào tới.

Cách khoanh vùng nhanh nhất là gọi thử endpoint từ một mạng khác, ví dụ từ điện thoại dùng dữ liệu di động. Nếu gọi được từ ngoài, vấn đề nằm ở phía TradingView. Nếu không gọi được, vấn đề nằm ở hạ tầng của bạn.

Một nguyên nhân nữa cần kiểm tra là đường dẫn. Nhiều framework coi đường dẫn có dấu gạch chéo ở cuối và không có là hai đường dẫn khác nhau. Nếu alert trỏ tới đường dẫn có dấu gạch chéo mà ứng dụng chỉ đăng ký không có, request sẽ trả về lỗi không tìm thấy.

Nhóm 3: server nhận nhưng nội dung sai

Nhóm lỗi này dễ sửa nhất vì bạn có bằng chứng cụ thể, miễn là bạn ghi log nội dung thô.

Nguyên nhân thứ nhất là JSON sai cú pháp: thiếu dấu phẩy, thừa dấu phẩy ở cuối, thiếu dấu nháy kép, hoặc dùng nháy đơn. Cách kiểm tra là in nội dung thô ra và đối chiếu từng ký tự với nội dung bạn soạn.

Nguyên nhân thứ hai là giá trị rỗng. Khi chỉ báo chưa đủ dữ liệu, giá trị của nó có thể rỗng, và nếu bạn ghép thẳng vào JSON, chuỗi sẽ chứa một giá trị không phải số. Server sẽ từ chối payload đúng như thiết kế, nhưng nguyên nhân thật nằm ở phía script.

Nguyên nhân thứ ba là số nằm trong dấu nháy kép. Khi đó server nhận chuỗi thay vì số, và các phép tính khối lượng có thể ra kết quả sai hoặc lỗi.

Nguyên nhân thứ tư là dấu nháy kép nằm trong giá trị. Nếu tên chiến lược hoặc ghi chú chứa dấu nháy kép, cấu trúc JSON bị phá vỡ.

Nguyên nhân thứ năm là nội dung bị cắt. Một số proxy hoặc cấu hình có giới hạn kích thước, và payload dài có thể bị cắt mà không có thông báo rõ ràng.

Nhóm 4: lệnh không được đặt dù dữ liệu đúng

Khi payload đúng và server xử lý bình thường mà không có lệnh nào, nguyên nhân thường nằm ở phần kiểm tra trước khi gửi.

Năm nguyên nhân thường gặp. Thứ nhất là mã không nằm trong danh sách cho phép. Thứ hai là khối lượng sau khi làm tròn bằng không, và bot được thiết kế đúng là bỏ qua trong trường hợp này. Thứ ba là giá trị lệnh dưới mức tối thiểu của sàn. Thứ tư là số dư hoặc sức mua không đủ. Thứ năm là bot đang ở chế độ tạm dừng bằng cờ cấu hình mà bạn quên bật lại.

Điểm quan trọng là cả năm trường hợp này đều nên được ghi log rõ ràng. Nếu bot bỏ qua lệnh mà không ghi gì, bạn sẽ tưởng hệ thống hỏng trong khi thực ra nó đang làm đúng.

Nhóm 5: lệnh đặt sai

Đây là nhóm lỗi nguy hiểm nhất vì nó không gây ra thông báo lỗi mà trực tiếp tạo ra rủi ro.

Bốn dạng sai phổ biến. Thứ nhất là sai khối lượng, thường do không làm tròn theo bước khối lượng của sàn, hoặc do dùng một con số cố định cho mọi cặp. Thứ hai là sai cặp giao dịch, do gõ cứng mã trong payload rồi nhân bản alert sang cặp khác mà không sửa, hoặc do thiếu hậu tố tên cặp ở những broker có hậu tố. Thứ ba là sai hướng lệnh, do ánh xạ giữa chuỗi hành động và loại lệnh không nhất quán. Thứ tư là sai mức dừng lỗ, do khoảng cách dừng lỗ nhỏ hơn mức tối thiểu của sàn, hoặc do làm tròn sai số chữ số thập phân.

Cách phòng ngừa hiệu quả nhất là kiểm tra chéo giữa payload và quyết định. Trước khi gửi lệnh, bot nên ghi log một dòng tóm tắt gồm mã, hướng, khối lượng, giá, mức dừng lỗ. Khi nhìn dòng log này, bạn sẽ phát hiện ngay những con số vô lý.

Nhóm 6: trùng lệnh

Đây là nhóm lỗi có hậu quả tài chính rõ ràng nhất và cũng có nguyên nhân rõ ràng nhất.

Ba nguyên nhân. Thứ nhất, chế độ kiểm tra trong alert được đặt là kiểm tra liên tục trong nến. Trong một nến, điều kiện có thể thoả rồi không thoả nhiều lần, và mỗi lần đều gửi một webhook.

Thứ hai, server không có cơ chế chống trùng theo mã tín hiệu. Không có cơ chế này, mọi payload đều được xử lý, bất kể đã xử lý trước đó.

Thứ ba, bot bị khởi động lại và mất bộ nhớ chống trùng. Nếu bộ nhớ chống trùng chỉ nằm trong bộ nhớ RAM, một lần triển khai phiên bản mới là đủ để bot quên hết.

Một nguyên nhân phụ cần kể tới là bạn tự tạo hai alert cho cùng một điều kiện trong lúc thử nghiệm và quên tắt một cái. Đây là lỗi rất hay gặp trong giai đoạn thiết lập, và cách phòng là đặt tên alert theo quy ước rồi rà danh sách định kỳ.

Nhóm 7: mất tín hiệu âm thầm

Đây là nhóm lỗi tệ nhất, vì không có bất kỳ dấu hiệu nào cho tới khi bạn nhận ra kết quả giao dịch khác thường.

Bốn cơ chế có thể gây ra mất tín hiệu. Thứ nhất là alert hết hạn, dừng gửi, không thông báo cho ai. Thứ hai là gói TradingView hết hạn, cũng không thông báo tới server của bạn. Thứ ba là tiến trình server dừng do lỗi hoặc do máy chủ khởi động lại mà không tự chạy lại. Thứ tư là đầy đĩa do log phình to, khiến ứng dụng không ghi được và có thể dừng.

Cách phòng gồm hai lớp. Lớp thứ nhất là nhịp tim: một alert bắn định kỳ và server ghi lại thời điểm nhận. Nếu quá khoảng thời gian cấu hình mà không có nhịp tim, bạn biết là hệ thống đã đứt ở đâu đó. Lớp thứ hai là giới hạn dung lượng log với xoay vòng, để đĩa không bao giờ đầy.

Một cách kiểm tra thủ công định kỳ rất đáng làm: mỗi tuần, mở danh sách alert và so với danh sách bạn ghi ngoài. Hai danh sách lệch nhau nghĩa là có alert đã biến mất.

Quy trình gỡ lỗi sáu bước

Khi có sự cố, hãy đi theo trình tự này để không bỏ sót.

Bước một, xác nhận hiện tượng bằng dữ liệu chứ không bằng cảm giác. Cụ thể là số tín hiệu nhận được hôm nay, số lệnh được đặt, và thời điểm bất thường bắt đầu.

Bước hai, kiểm tra alert. Alert còn tồn tại không, còn hạn không, được tạo từ đúng script và đúng cặp không.

Bước ba, kiểm tra đường tới server. Gọi thử endpoint từ ngoài mạng, xem có phản hồi đúng không.

Bước四, kiểm tra log phía server. Tìm xem có request nào tới trong khoảng thời gian bất thường không, và nội dung thô là gì.

Bước năm, kiểm tra quyết định. Nếu có request tới mà không có lệnh, đọc log phần kiểm tra để biết bot đã từ chối vì lý do gì.

Bước sáu, kiểm tra sàn. Nếu bot đã gửi lệnh, đọc phản hồi của sàn để biết lệnh bị từ chối hay đã khớp.

Sau khi sửa xong, hãy chạy lại trên môi trường thử trước, rồi mới bật lại tiền thật với khối lượng nhỏ nhất. Điều tệ nhất là bật lại ngay với khối lượng bình thường và gặp lại đúng lỗi cũ.

Bộ công cụ gỡ lỗi nên có sẵn

Chuẩn bị sẵn bốn thứ sẽ giúp bạn gỡ lỗi nhanh hơn nhiều trong tương lai.

Thứ nhất là một dịch vụ nhận webhook tạm thời, để kiểm tra nội dung thô mà không phụ thuộc vào server của bạn.

Thứ hai là một script nhỏ gửi payload giả tới endpoint của bạn, để kiểm thử các trường hợp biên như thiếu khoá, sai khoá, khối lượng lớn, mã lạ.

Thứ ba là một tệp ghi chú ghi lại các sự cố đã gặp cùng nguyên nhân thật. Ba tháng sau, khi gặp sự cố tương tự, cẩm nang này tiết kiệm cho bạn nhiều giờ.

Thứ tư là một bảng theo dõi danh sách alert, gồm tên, cặp, khung, chiến lược, ngày tạo và ngày cần kiểm tra lại.

Nhóm 8: lỗi môi trường ít được nghĩ tới

Nhóm này ít gặp hơn nhưng khi xảy ra thì rất khó tìm, vì nó không nằm ở logic mà nằm ở môi trường chạy.

Lỗi thứ nhất là lệch múi giờ. TradingView gửi thời gian theo một múi giờ nhất định, máy chủ của bạn có thể đặt múi giờ khác, và sàn thì dùng múi giờ của nó. Khi ba mốc này lệch nhau, mọi so sánh theo ngày đều sai, và bạn có thể gặp tình huống lệnh hôm nay bị tính vào hôm qua. Cách xử lý là quy đổi mọi thứ về một múi giờ tham chiếu duy nhất khi ghi log, và ghi rõ múi giờ trong tên tệp log.

Lỗi thứ hai là mã hoá ký tự. Nếu tên chiến lược hoặc ghi chú có dấu tiếng Việt và bị mã hoá sai ở một tầng nào đó, chuỗi sẽ hỏng và có thể làm JSON không phân tích được. Cách phòng là giữ mọi trường trong payload ở dạng không dấu, chỉ dùng chữ cái, chữ số và gạch ngang.

Lỗi thứ ba là số thực và dấu thập phân. Trong một số ngôn ngữ và một số cấu hình hệ thống, dấu phẩy được dùng làm dấu thập phân. Khi đó giá trị số có thể bị hiểu sai. Cách phòng là không dùng cấu hình theo vùng cho tiến trình chạy bot.

Lỗi thứ tư là giới hạn của proxy. Một số proxy có giới hạn kích thước thân request hoặc có thời gian chờ ngắn, khiến payload dài bị cắt hoặc request bị ngắt. Dấu hiệu là lỗi phân tích cú pháp chỉ xuất hiện khi payload dài, còn payload ngắn thì bình thường.

Lỗi thứ năm là ký tự đặc biệt trong dữ liệu. Nếu mã cặp hoặc tên chiến lược chứa ký tự đặc biệt, các phần kiểm tra bằng so khớp chuỗi có thể hoạt động không như bạn mong đợi, đặc biệt khi so khớp theo mẫu.

Ba sự cố điển hình và cách tìm ra nguyên nhân

Ba tình huống dưới đây là những sự cố lặp lại nhiều nhất trong thực tế, và mỗi tình huống có một cách khoanh vùng riêng.

Sự cố thứ nhất: bot chạy tốt ba ngày đầu rồi không đặt lệnh nào nữa. Cách khoanh vùng là kiểm tra ba thứ theo thứ tự. Trước tiên xem server còn nhận được request nào không, nếu không thì vấn đề ở phía alert hoặc hạ tầng. Nếu có nhận mà không có lệnh, xem log phần kiểm tra để biết lý do từ chối. Nếu có gửi lệnh mà sàn từ chối, đọc phản hồi của sàn. Trong thực tế, nguyên nhân phổ biến nhất của tình huống này là alert hết hạn hoặc bộ nhớ chống trùng giữ tín hiệu quá lâu nên bot coi mọi tín hiệu mới là trùng.

Sự cố thứ hai: bot khớp một lệnh rất lớn so với bình thường. Cách khoanh vùng là đọc log ở ba thời điểm: lúc nhận payload, lúc tính khối lượng, và lúc gửi lệnh. So sánh ba con số này sẽ chỉ ra khâu sai. Nguyên nhân phổ biến nhất là số dư được đọc sai thời điểm, hoặc tỉ lệ phân bổ bị nhân đôi do xử lý cùng một tín hiệu hai lần, hoặc bước khối lượng bị làm tròn theo hướng tăng.

Sự cố thứ ba: bot đặt lệnh sai cặp giao dịch. Cách khoanh vùng là so mã trong payload với mã trong lệnh đã đặt. Nếu payload đúng mà lệnh sai, lỗi nằm ở bảng ánh xạ hoặc ở chỗ ghép hậu tố. Nếu payload đã sai, lỗi nằm ở phía script hoặc ở alert được tạo từ sai cặp. Nguyên nhân phổ biến nhất là nhân bản alert từ chart này sang chart khác rồi quên kiểm tra lại phần nội dung.

Phòng ngừa: mười việc nên làm ngay hôm nay

Danh sách này không phải để đối phó sự cố, mà để giảm số sự cố bạn sẽ gặp.

Một, bật chế độ gửi khi nến đóng cho mọi alert dùng để đặt lệnh. Hai, thêm mã tín hiệu vào payload và có cơ chế chống trùng ở phía server. Ba, ghi log nội dung thô đúng như nhận được, không qua xử lý. Bốn, ghi log quyết định cùng lý do, đặc biệt là lý do từ chối.

Năm, tạo một alert nhịp tim bắn định kỳ. Sáu, đặt giới hạn trần khối lượng và trần số lệnh mở. Bảy, kiểm tra rằng mọi nhánh lỗi đều được ghi log, không có chỗ nào nuốt lỗi trong im lặng. Tám, ghi lại danh sách alert ra ngoài và kiểm tra định kỳ so với thực tế.

Chín, đặt giới hạn dung lượng log với xoay vòng. Mười, chạy thử toàn bộ hệ thống trên môi trường demo sau mỗi lần thay đổi cấu hình, dù thay đổi đó có vẻ nhỏ.

Cách ghi log để lần sau gỡ nhanh hơn

Chất lượng log quyết định tốc độ bạn gỡ được lỗi trong tương lai. Một dòng log tốt trả lời được câu hỏi vì sao lệnh đó được đặt, kể cả sáu tháng sau.

Bốn nhóm thông tin mỗi lần xử lý nên ghi. Thứ nhất là thời điểm nhận và nội dung thô của payload, để bạn biết chính xác cái gì đã tới. Thứ hai là kết quả các bước kiểm tra, gồm cả những bước bị từ chối cùng lý do. Thứ ba là quyết định cuối cùng gồm mã, hướng, khối lượng, giá và mức dừng lỗ. Thứ tư là phản hồi của sàn, gồm mã lệnh nếu thành công và mã lỗi nếu thất bại.

Ba nguyên tắc trình bày log. Một là ghi theo định dạng có cấu trúc, ví dụ mỗi dòng một đối tượng JSON, để bạn lọc và thống kê bằng công cụ thay vì đọc bằng mắt. Hai là dùng cùng một mã định danh cho một tín hiệu xuyên suốt các dòng log liên quan, để bạn nối được toàn bộ vòng xử lý của tín hiệu đó. Ba là không ghi khoá bí mật và API key, kể cả khi đang gỡ lỗi, vì log thường được sao lưu và chia sẻ.

Một mẹo rất hữu ích là ghi cả những lần bot chủ động không làm gì. Nếu log chỉ ghi khi có lệnh được đặt, bạn sẽ không phân biệt được hai tình huống hoàn toàn khác nhau: tín hiệu không tới, và tín hiệu tới nhưng bot từ chối. Hai tình huống này cần cách xử lý khác hẳn nhau, nên việc ghi đủ là điều kiện để bạn chẩn đoán đúng ngay từ đầu.

Nguyên tắc cuối cùng: sửa lỗi phải sửa từ gốc

Một cám dỗ rất tự nhiên khi gặp lỗi là sửa ở chỗ gần nhất với triệu chứng. Ví dụ thấy bot không đặt lệnh thì thêm một nhánh thử lại, thấy lệnh bị từ chối vì khối lượng thì hạ khối lượng xuống bằng tay, thấy tín hiệu bắn trùng thì tăng thời gian chống trùng lên thật dài.

Cách làm này có thể làm triệu chứng biến mất nhưng để lại hai vấn đề. Thứ nhất, nguyên nhân gốc vẫn còn và sẽ biểu hiện ở chỗ khác, thường là vào lúc bạn ít ngờ nhất. Thứ hai, bạn đang tích luỹ những thay đổi không có căn cứ, và sau vài tháng sẽ không ai hiểu vì sao hệ thống lại có những con số đó.

Nguyên tắc nên theo là mỗi lần sửa đều phải trả lời được câu hỏi nguyên nhân gốc là gì, và thay đổi này loại bỏ nguyên nhân đó chứ không chỉ che triệu chứng. Nếu bạn chưa trả lời được, hãy dành thêm thời gian để tìm hiểu bằng cách ghi thêm log và tái hiện lại tình huống trong môi trường thử.

Một thói quen nữa rất đáng làm là sau mỗi sự cố nghiêm trọng, hãy viết lại một đoạn ngắn gồm ba phần: chuyện gì đã xảy ra, nguyên nhân gốc là gì, và thay đổi nào đã được thực hiện để nó không lặp lại. Ba đoạn này, tích luỹ theo thời gian, là tài sản lớn nhất khi bạn vận hành bot giao dịch dài hạn.

Kết luận

Bảy nhóm lỗi trong bài này bao phủ gần như toàn bộ sự cố thực tế khi dựng webhook TradingView. Điều đáng chú ý là phần lớn lỗi không nằm ở code phía server, mà nằm ở cấu hình alert và ở việc thiếu cơ chế chống trùng và giám sát.

Hai việc nên làm ngay cả khi hệ thống đang chạy tốt là thêm nhịp tim để phát hiện lỗi im lặng, và ghi log nội dung thô cùng quyết định để lần sau gỡ lỗi nhanh hơn.

Nếu bạn muốn có người cùng rà lại toàn bộ hệ thống và chỉ ra những lỗi tiềm ẩn trước khi chúng gây thiệt hại, hãy xem Bootcamp TradingView Webhook Bot của Hướng Nghiệp AI. Khoá học có buổi 1-1 để kiểm tra trực tiếp bot của bạn.

Đọc tiếp trong chuỗi: TradingView Webhook Bot là gì, cách tạo alert TradingView gửi webhook, bảo mật webhook TradingView và VPS chạy bot TradingView Webhook 24/7.