Өдөр бүр тогтсон цагт тасардаг бол ихэнхдээ нэг холболт 24 цаг хүрсэн. Санамсаргүй тасардаг бол ping-д хариу өгөөгүй. Холболт байгаа мөртлөө мэдээлэл ирэхгүй бол бүртгэл (subscription) дууссан. 2026-02-20-ноос хойш огт ирэхгүй болсон бол хэрэгсэл зогссон listenKey интерфэйсийг ашигласаар байж магадгүй. Эхний гурвыг хэрэгсэл өөрөө дахин холбогдож, дахин бүртгүүлснээр шийднэ; сүүлчийнх нь зөвхөн хэрэгслийн шинэчлэл эсвэл өөр хэрэгслээр л шийдэгдэнэ.
Эхлээд аль урсгал тасарсныг тодорхойл: зах зээлийн мэдээлэл ба дансны мэдээлэл тусдаа
Ихэнх арилжааны хэрэгсэл Binance-тэй нэгээс олон холболт нээж ажилладаг. Лааны график, захиалгын дэвтрийн гүн, сүүлийн хэлцэл зэрэг нийтийн зах зээлийн мэдээлэл нэг холболтоор ирнэ. Таны өөрийн захиалгын өөрчлөлт, биелэлтийн мэдээ, үлдэгдлийн хөдөлгөөн өөр холболтоор ирэх бөгөөд Binance-ийн хөгжүүлэгчийн баримт бичигт үүнийг User Data Stream буюу дансны мэдээллийн урсгал гэж нэрлэдэг.
Энэ хоёр өөр аргаар баталгаажиж, өөр шалтгаанаар тасардаг. Зах зээлийн мэдээлэлд API түлхүүр огт хэрэггүй; дансны урсгалд харин таны хэрэгсэлд өгсөн түлхүүрээр бүртгүүлэх шаардлагатай. Тийм учраас ердийн шинж тэмдэг иймэрхүү харагдана: график хэвийн шинэчлэгдэж байгаа ч хэрэгсэл дэх лимит захиалга “биелээгүй” хэвээр, гэтэл Binance-ийн вэб дээр тэр захиалга аль хэдийн биелсэн харагдана.
Ийм зөрүү гарвал түлхүүрийн эрхэд яаран бүү хүр. Зөвхөн унших, арилжаалах зэрэг эрх нь хэрэгсэл мэдээлэл харах, захиалга өгөх эсэхийг шийддэг; урсгал холбогдсон эсэхтэй холбоогүй. Дансны урсгал тасарсан ч хэрэгсэл ихэвчлэн REST интерфэйсээр өөрөө асууж чадна. Зарим нь урсгал ажиллахгүй үед тодорхой хугацаанд давтан асуух горимд шилждэг: шинэчлэл удааширч, хүсэлт олширно. Энэ нь доор өгүүлэх хүсэлтийн хязгаартай холбогдоно.
2026 оны 2-р сараас хойш listenKey ашигладаг хэрэгсэл яагаад шинэчлэл авахаа больсон бэ
Хуучин хэрэгслүүд дансны урсгалд ингэж бүртгүүлдэг байсан: эхлээд POST /api/v3/userDataStream дуудаж listenKey авна, түүгээр wss://stream.binance.com-д холбогдоно, дараа нь PUT дуудлагаар тогтмол сунгана. Spot дээр энэ зам хаагдсан.
Spot API-ийн өөрчлөлтийн тэмдэглэл (changelog)-д хугацааны дараалал ингэж бичигдсэн:
- 2025-04-07:
wss://stream.binance.com:9443дээр listenKey ашиглан дансны мэдээлэл авах аргыг хуучирсан (deprecated) гэж зарлаж, оронд нь WebSocket API дээр бүртгүүлэхийг санал болгосон. - 2025-10-24:
wss://stream.binance.com-д зориулсан listenKey-тэй холбоотой бүх баримтыг spot баримт бичгээс хассан; интерфэйс өөрөө түр хугацаанд ажилласаар байсан. - 2026-01-21: 2026-02-20 07:00 (UTC)-ээс эхлэн дараах интерфэйсүүд ашиглах боломжгүй болно гэж зарласан: REST-ийн
POST,PUT,DELETE /api/v3/userDataStream, мөн WebSocket API-ийнuserDataStream.start,userDataStream.ping,userDataStream.stop.
Энэ өдрөөс хойш холболтын кодоо шинэчлээгүй хэрэгсэл listenKey авч чадахгүй, эсвэл хуучин key-гээ сунгаж чадахгүй. Шинж тэмдэг нь тодорхой: зах зээлийн мэдээлэл хэвийн, дансны урсгал тодорхой нэг өдрөөс эхлэн дахин сэргээгүй, хэрэгслээ дахин асаасан ч нэмэргүй. Энэ тохиолдолд дансны талаас та юу ч хийж чадахгүй: шинэ түлхүүр, нэмэлт эрх, IP зөвшөөрлийн жагсаалтын өөрчлөлт аль нь ч тусгүй. Хэрэгслийн шинэчлэлийн тэмдэглэл эсвэл тусламжийн хуудсыг үзэж, WebSocket API-аар бүртгүүлэх аргад шилжсэн эсэхийг шалга. Шилжээгүй бол хөгжүүлэгчид хандах, эсвэл шинэчлэгдэх хүртэл автомат арилжааг нь унтраа. Ингэснээр хэрэгсэл хуучирсан захиалгын төлөв дээр тулгуурлан захиалга өгсөөр байхаас сэргийлнэ.
Энэ зогсолт spot-д хамаарна. Маржин дансны урсгалд албан ёсны баримтад listenToken гэсэн тусдаа бүртгүүлэх заавар бий, фьючерс зэрэг бусад бүтээгдэхүүн ч өөр өөрийн User Data Stream баримттай. Иймд энд бичсэн дүрмийг тэдгээрт шууд хэрэглэж болохгүй.
Одоогийн хоёр бүртгүүлэх арга ба таны түлхүүрийн төрөл
Одоо spot дансны урсгалд WebSocket API-ийн холболт (wss://ws-api.binance.com:443/ws-api/v3) дээр бүртгүүлдэг. Баримт бичигт бүртгэл эхлүүлэх хоёр аргыг заажээ:
userDataStream.subscribe: эхлээдsession.logon-оор холболтыг бүхэлд нь тодорхой нэг түлхүүрийн нэрээр нэвтрүүлж, дараа нь тэр дансны мэдээлэлд бүртгүүлнэ. Баримтад энэ арга Ed25519 түлхүүрээр баталгаажсан WebSocket холболт шаарддаг гэж бичсэн.userDataStream.: урьдчилан нэвтрэх шаардлагагүй; бүртгүүлэх хүсэлт бүрд API түлхүүр, цагийн тэмдэг (timestamp), гарын үсгийг хавсаргана. Өөрчлөлтийн тэмдэглэлд энэ нь Ed25519 шаардахгүй, HMAC, RSA гээд ямар ч төрлийн түлхүүртэй ажиллана гэж заасан.subscribe. signature
Энэ нь таны хэрэгсэлд түлхүүр өгөх аргад шууд нөлөөлнө. Жишээ нь та хэрэгсэлдээ HMAC түлхүүр үүсгэж өгсөн байтал “бодит цагийн мэдээлэлд Ed25519 түлхүүр хэрэгтэй” гэж мэдэгдвэл тэр нь эхний аргыг ашиглаж байна. Шаардлагын дагуу Ed25519 түлхүүр үүсгэж болно, эсвэл гарын үсгээр бүртгүүлэх арга руу шилжиж болох эсэхийг хөгжүүлэгчээс асууж болно. Төрөл солих нь шинэ түлхүүр үүсгэнэ гэсэн үг тул хуучныг нь устгахаа бүү мартаарай. Дарааллыг төлөвлөгөөт түлхүүр солилт ба яаралтай цуцлалт-аас, төрлүүдийн ялгааг HMAC, RSA, Ed25519-ийн тухай заавар-аас үзээрэй.
Хоёрдугаар аргад арчилгааны нэг нарийн зүйл бий: цагийн тэмдэг шаарддаг тул төхөөрөмжийн цаг зөрвөл бүртгэл амжилтгүй болж болно. Энэ нь энгийн гарын үсэгтэй хүсэлтэд -1021 гарахтай ижил зарчим бөгөөд шалгах аргыг цаг болон гарын үсгийн алдааг тусад нь шалгах заавраас харна уу. Мөн session.logout нь зөвхөн эхний аргаар үүсгэсэн бүртгэлийг хаадаг; гарын үсгээр хийсэн бүртгэлд нөлөөлөхгүй тул түүнийг userDataStream.unsubscribe-ээр хаана.
Өдөр бүр бараг ижил цагт тасардаг: 24 цагийн холболтын хязгаар
Хамгийн түгээмэл бөгөөд хамгийн бага санаа зовох хэрэгтэй тохиолдол нь энэ.
Баримт бичигт шууд бичжээ: нэг холболт зөвхөн 24 цаг хүчинтэй, 24 цаг хүрмэгц таслагдана гэж хүлээж, дахин холбогдохыг клиент өөрөө зохицуулах ёстой. Серверт засвар хийхийн өмнө serverShutdown үйл явдал илгээгээд дараа нь холболтыг тасалдаг бөгөөд аль болох хурдан шинэ холболт нээхийг шаарддаг.
Гол нь бүртгэл холболт дээр тогтдог. Холболт тасрахад түүн дээрх бүртгэл хамт алга болно. Шинэ холболт нээгдсэний дараа хэрэгсэл дахин нэвтрэх эсвэл гарын үсгээр дахин бүртгүүлэх ёстой; өөрөө сэргэдэггүй. Хэвийн арчилгаатай хэрэгслийн лог дээр ойролцоогоор өдөрт нэг удаа “дахин холбогдох — дахин бүртгүүлэх” гэсэн бичлэг харагдах ч интерфэйс дээр бараг мэдрэгдэхгүй.
Харин өдөр бүр нэг цагаас хойш шинэчлэл зогсож, хэрэгслийг гараар дахин асаах хүртэл сэргэхгүй байвал хэрэгсэл дахин холбогдсон ч дахин бүртгүүлээгүй, эсвэл дахин бүртгүүлэх оролдлого нь чимээгүйхэн амжилтгүй болсон байна. Үүнийг зөвхөн хэрэгслийн талаас засна. Таны өгч чадах гол сэжүүр бол “өдөр бүр хэдэн цагаас эхэлж зогсдог” гэдэг.
Тогтмол бус тасралт: 20 секунд тутмын ping-д хариу өгөөгүй
Одоогийн баримтын дагуу сервер холболт руу 20 секунд тутамд ping фрейм илгээж, нэг минутын дотор pong ирэхгүй бол холболтыг тасална. Клиент ping хүлээн авмагц ижил агуулгатай pong-оор аль болох хурдан хариулах ёстой. Клиент өөрөө урьдчилан pong илгээхийг зөвшөөрдөг ч баримтад энэ нь холболт тасрахаас сэргийлэхгүй гэж тусгайлан тэмдэглэжээ.
Интернэт дэх зарим хуучин асуулт хариултад “3 минут тутам ping илгээдэг” гэж бичсэн байдаг. Энэ бол өмнөх дүрэм; алдаа хайхдаа хөгжүүлэгчийн баримтын одоогийн хувилбарыг баримжаал.
Тогтмол бус тасралт гарвал эхлээд хэрэгсэл хаана ажиллаж байгааг хар. Зөөврийн компьютер дээр суулгасан программ компьютер унтах, тагийг хаах, сүлжээ солигдох үед зогсож, pong илгээж чадахгүй. Үүлэн сервер эсвэл контейнерт ажиллаж буй хэрэгсэл нөөц дүүрэх, процесс удаан гацах үед ping-ийг алгасаж болно. Хэрэгслийн WebSocket сан pong-ийг автоматаар илгээдэг эсэхийг хөгжүүлэгч л баталгаажуулна; дансны тохиргоогоор үүнийг шийдэх боломжгүй.
Энэ төрлийн тасралтыг 24 цагийн хязгаараас ялгах гол шинж нь тогтмол бус байдал юм. Сүүлийн хэдэн тасралтын цагийг тэмдэглэ: зай нь 24 цагт ойр бол өмнөх хэсэгт, жигд бус бөгөөд компьютер унтсан эсвэл серверийн ачаалал ихэссэн цагтай давхцаж байвал энэ хэсэгт хамаарна.
Холболт тасраагүй ч мэдээлэл ирэхгүй: бүртгэл өөрөө дууссан
Илүү далд нэг тохиолдол бий: холболт хэвээр, хэрэгслийн холболтын заагч ногоон байгаа ч дансны мэдээлэл ирэхээ больсон.
User Data Stream-ийн баримтад eventStreamTerminated үйл явдал хэзээ илгээгддэгийг жагсаасан бөгөөд spot-д хамаарах нь хоёр: session.logout-оор нэвтрэлтэд суурилсан бүртгэл дууссан, эсвэл userDataStream.unsubscribe-ээр бүртгэлийг зогсоосон. Энэ үйл явдлын дараа тухайн бүртгэлээр мэдээлэл дахин ирэхгүй. Хэрэгсэл данс солих, гарах үедээ эдгээр аргын аль нэгийг дуудаад дахин бүртгүүлээгүй бол яг энэ байдалд орно.
Хэрэгсэл session.status-аар одоогийн сешнд идэвхтэй бүртгэл байгаа эсэхийг шалгаж болно: хариуны userDataStream талбар true бол дор хаяж нэг бүртгэл идэвхтэй, false бол нэг ч байхгүй. session.subscriptions нь идэвхтэй бүх бүртгэлийг жагсаана.
Олон дансыг зэрэг удирддаг хэрэгсэлд анхаарах нэг хязгаар бий: нэг холболт дээр нэг дансанд зөвхөн нэг бүртгэл байж болно.
Хэт яаран дахин холбогдвол нэг гарах хаягтай IP-г хязгаарт оруулж болно
Тасарсны дараа дахин холбогдох нь зөв. Асуудал нь дахин холбогдох хэмнэлд байдаг.
WebSocket API-ийн холболтыг IP хаягаар тоолдог: баримтад нэг IP 5 минут тутамд хамгийн ихдээ 300 удаа холбогдох оролдлого хийж болох бөгөөд холболт бүр 2 нэгж хүсэлтийн жин (weight) зарцуулна гэж заасан. Жин мөн IP-аар хуримтлагдах тул нэг гарах хаягийн ард байгаа бүх холболт нэг хязгаарыг хуваалцана. Хэтэрвэл хүсэлт 429 буцаана; 429 ирсэн хойно ч үргэлжлүүлэн илгээвэл IP автоматаар хаагдаж, хаагдсан хугацаанд 418 буцна. Давтан зөрчсөн тохиолдолд хаалтын хугацаа 2 минутаас 3 хоног хүртэл уртасдаг.
Тасармагц завсаргүй, хязгааргүй дахин холбогддог хэрэгсэл сүлжээ тогтворгүй үед өөрийгөө амархан энэ шугамд хүргэнэ. Үүнээс гадна үүлэн хэрэгсэл олон хэрэглэгчийг нэг гарах IP-д нэгтгэж болох тул нэг хүний дахин холболтын шуурга нэг сервер дээрх бусад холболтыг ч чирж унагаж болзошгүй. Дахин холбогдох хооронд хүлээх хугацааг аажмаар уртасгаж, 429 ирвэл хариу дахь retryAfter-т заасан хүртэл зогсох ёстой. Энэ нь REST хүсэлт хязгаарт хүрэх үеийн зарчимтай ижил бөгөөд дэлгэрэнгүйг 429 үед түр зогсоо заавраас үзнэ үү.
Амархан анзаарагдахгүй нэг зүйл: тасарсан хугацаанд болсон дансны үйл явдлыг дахин холбогдсоны дараа нөхөж илгээнэ гэж албан ёсны баримтад заагаагүй. Найдвартай арга бол дахин бүртгүүлэх бүрийн дараа асуулгын интерфэйсээр нээлттэй захиалга, үлдэгдлээ нэг шалгаад, дараа нь л урсгалд найдах. Ингэдэггүй хэрэгсэл аль хэдийн биелсэн эсвэл цуцлагдсан захиалгыг нээлттэй гэж бодсоор дараагийн шийдвэрээ гаргаж болно.
Хэрэгслийн хөгжүүлэгчид хандахаасаа өмнө эдгээрийг бэлд
Дансны урсгалын ихэнх асуудлыг эцэстээ хэрэгслийн тал код засах эсвэл шинэ хувилбар гаргаж шийддэг. Таны хийж чадах зүйл бол нууц мэдээлэл задруулахгүйгээр, нөгөө тал шууд олж харахуйц тодорхой тайлбарлах.
- Тасарсан цаг (цагийн бүсийг заа), ойролцоогоор 24 цаг тутам давтагддаг эсэх.
- Тасарсан үед зах зээлийн мэдээлэл шинэчлэгдсээр байсан эсэх: ингэж дансны урсгал уу, бүх сүлжээ үү гэдгийг ялгана.
- Хэрэгслийн одоогийн хувилбар, хамгийн сүүлд шинэчлэгдсэн огноо, ялангуяа 2026-02-20-ноос хойш шинэчлэгдсэн эсэх.
- Өгсөн түлхүүрийн төрөл: HMAC, RSA эсвэл Ed25519 (зөвхөн төрлийг нь хэл, түлхүүрийг өөрийг нь бүү илгээ).
- Хэрэгсэл хаана ажилладаг: өөрийн компьютер, үүлэн сервер, эсвэл хэрэгслийн талын үйлчилгээ; компьютер дээр бол тэр үед унтсан эсэх.
- Интерфэйс эсвэл лог дээр гарсан алдааны эх бичвэр, жишээ нь 429, 418 эсвэл хасах тэмдэгтэй алдааны код.
API түлхүүр, Secret, хувийн түлхүүрийн файл, гарын үсгийн мөрийг хэнд ч бүү илгээ, “дэмжлэгийн ажилтан” гэж танилцуулсан хүнд ч. Алдааны кодыг өөрийг нь хэрхэн ангилахыг эхлээд -2015, -1021, -1022, 429 алдааг шалгах заавраас, эсвэл эрх шалгах хэрэгсэлд алдааны кодоо оруулж дараа нь юуг шалгахаа харна уу.
Хэрэгслийн тал засвараа удаашруулж байгаа бөгөөд хэрэгсэл арилжааны эрхтэй бол эхлээд автомат захиалгыг нь зогсоож, шаардлагатай бол тэр түлхүүрийг устгах нь илүү аюулгүй. Бодит захиалгын төлөвийг харж чадахгүй автомат хэрэгсэл түр ашиглахгүй байхаас илүү эрсдэлтэй.