jeessy2/ddns-go · error
读取响应失败: %v
Error message
读取响应失败: %v
What it means
This error is thrown by the Tnet.hk DNS provider's internal request() helper in dns/tnethk.go:279 when io.ReadAll(resp.Body) fails after a successful HTTP round-trip to https://www.tnet.hk. The API call itself connected, but the response body could not be read — typically a mid-stream connection reset, timeout, or truncated response. It propagates out of create, modify and getRecordList as the returned error.
Source
Thrown at dns/tnethk.go:279
if err != nil {
return nil, fmt.Errorf("创建请求失败: %v", err)
}
// 设置请求头
req.Header.Set("Accept", "application/json")
// 发送请求
client := t.httpClient
resp, err := client.Do(req)
if err != nil {
return nil, fmt.Errorf("请求失败: %v", err)
}
defer resp.Body.Close()
// 读取响应
body, err := io.ReadAll(resp.Body)
if err != nil {
return nil, fmt.Errorf("读取响应失败: %v", err)
}
// 检查HTTP状态码
if resp.StatusCode != http.StatusOK {
return nil, fmt.Errorf("API请求失败,状态码: %d, 响应: %s", resp.StatusCode, string(body))
}
return body, nil
}
View on GitHub (pinned to 5874c2e666)
Solutions
- Retry the request — the failure is almost always transient network/stream related
- Check connectivity/stability to https://www.tnet.hk (curl the same endpoint) and any proxy in between
- Increase or verify the http.Client timeout used by the Tnethk provider
- Check Tnet.hk API status; a server dropping connections mid-response is on their side
Defensive patterns
Strategy: retry
Validate before calling
// Go: verify reachability before provider calls
resp, err := http.Get("https://www.tnet.hk")
if err != nil {
log.Fatalf("tnet.hk unreachable: %v", err)
}
resp.Body.Close() Try / catch
// Go
for i := 0; i < 3; i++ {
records, err := provider.GetRecordList(domain)
if err == nil {
break
}
if strings.Contains(err.Error(), "读取响应失败") {
time.Sleep(time.Duration(1<<i) * time.Second) // backoff and retry
continue
}
return err // non-transient
} Prevention
- Retry idempotent reads (getRecordList) with exponential backoff
- Run on a stable network path to tnet.hk; avoid flaky proxies/VPNs for API traffic
- Monitor DNS provider API reachability from the host running the tool
- Set a http.Client timeout generous enough for slow Tnet responses
When it happens
Trigger: Any signed request to the Tnet.hk API (record create, modify, or list) where the server closes/resets the connection partway through the response, the 30s client timeout fires while reading the body, or a proxy/NAT truncates the stream.
Common situations: Unstable network or VPN to tnet.hk; server-side gateway timeouts returning partial bodies; corporate middleboxes killing keep-alive connections; transient outages of the Tnet API.
Related errors
AI-assisted analysis of jeessy2/ddns-go@5874c2e666 (2026-09-03).
Data as JSON: /api/errors/0f21ee378f1ed003.
Report an issue: GitHub.