어떤 버그는 매번 실패합니다. 어떤 버그는 일정한 주기로 실패합니다. 2026.9에서 수정된 Huobi 및 HTX 서명 결함은 후자에 속했고, 그 때문에 원인을 찾아내기가 훨씬 어려웠습니다. UTC가 아닌 곳에서 실행되는 호스트에서는 매일 일부 시간 동안 비공개 요청이 실패하고 나머지 시간에는 정상적으로 동작했는데, 이는 누군가가 그 패턴이 시계와 맞물려 있다는 것을 알아채기 전까지는 영락없이 간헐적인 인증 문제처럼 보입니다.
서로 다른 두 시계로 만들어진 타임스탬프
Huobi와 HTX는 모두 서명된 요청에 yyyy-MM-ddTHH:mm:ss 형식의 UTC 타임스탬프를 담도록 요구합니다. TsgcWSAPI_Huobi와 TsgcWSAPI_HTX가 함께 사용하는 TsgcWS_API_Huobi_Base의 서명 루틴은 이 타임스탬프를 서로 다른 두 출처에서 만들고 있었습니다. 날짜 부분은 로컬 시스템 시계에서, 시간 부분은 UTC에서 가져온 것입니다. 대부분의 시간 동안, 대부분의 머신에서는 로컬 날짜와 UTC 날짜가 같은 값이기 때문에 아무 문제도 없어 보였습니다. UTC 자정 근처에서, 로컬 시간대 오프셋 때문에 그 경계의 반대편에 놓이는 호스트에서는 날짜와 시간이 서로 어긋나기 시작했고, Huobi가 자체적으로 계산한 서명과 일치하지 않아 요청이 거부되었습니다.
이 수정은 날짜와 시간을 모두 동일한 UTC 값에서 가져옵니다:
uses
sgcBase_Helpers;
var
vUTC: TDateTime;
vTimeStamp: string;
begin
vUTC := sgcGetDateTimeAsUTC;
vTimeStamp := FormatDateTime('yyyy-mm-dd', vUTC) + 'T' +
FormatDateTime('hh:nn:ss', vUTC);
end;설정할 것은 없습니다. TsgcWSAPI_Huobi와 TsgcWSAPI_HTX 모두 동일한 이 서명 루틴을 호출하므로, 두 컴포넌트가 함께 수정됩니다:
uses
sgcWebSocket, sgcWebSocket_APIs;
var
oHuobi: TsgcWSAPI_Huobi;
begin
oHuobi := TsgcWSAPI_Huobi.Create(nil);
oHuobi.Client := oClient;
oHuobi.Huobi.ApiKey := 'your_api_key';
oHuobi.Huobi.ApiSecret := 'your_api_secret';
oClient.Active := True;
// Authentication now signs with a timestamp taken entirely from UTC.
oHuobi.SubscribeOrderUpdates('btcusdt');
end;로그에서 Huobi 또는 HTX 비공개 요청이 명확한 원인 없이 나타났다 사라졌다 하며 실패하는 것을 보셨다면, 특히 서버가 UTC로 실행되지 않는 경우라면 이것이 그 이유일 가능성이 매우 높습니다.
재연결 시 비공개 구독이 유실되던 문제
Huobi는 같은 작업에서 함께 수정된 별도의 재연결 결함, 즉 WatchDog가 재연결한 후 orders, balances, fills 같은 비공개 구독이 재전송되지 않던 문제의 영향을 받은 여러 거래소 클라이언트 중 하나이기도 했습니다. 재연결 자체는 성공했고 로그에도 그렇게 기록되었기 때문에, 연결이 끊기기 전까지 받고 있던 비공개 피드가 이제 조용히 사라졌다는 것을 알려주는 것은 아무것도 없었습니다. 이제 이 재전송은 재연결 후 공개 시장 데이터 구독을 이미 복원하던 것과 동일한 재구독 경로의 일부가 되었습니다.
업그레이드
두 수정 사항 모두 그대로 적용됩니다. 설정할 속성도, 변경할 코드도 없습니다. 서명은 이제 그냥 올바르게 계산되고, 재연결 재전송에는 이제 비공개 구독도 포함됩니다.
질문이나 피드백, 마이그레이션 관련 도움이 필요하신가요? 문의하기 — 실제로 코드를 작성한 사람들에게서 답변을 받으실 수 있습니다.