Intermittent pre-TLS connection failures from hkg1 Node.js Functions to a public HTTPS API

We are investigating intermittent connectivity from existing hkg1 Node.js 22 Functions to the public HTTPS endpoint green-cip.cn-shanghai.aliyuncs.com:443.

In one protected diagnostic deployment on 2026-10-09 around 23:19 UTC, an unsigned GET completed DNS, TCP and certificate-validated TLS and returned HTTP 404 in about 0.37 seconds. In another around 23:21 UTC, an unsigned GET and a fresh Node https POST with agent:false resolved the same destination address but did not complete TCP or TLS within their bounded 12- and 15-second measurements. The application fetch recorded UND_ERR_CONNECT_TIMEOUT. An independent control HTTPS endpoint responded in the failing invocation.

There was no failed vendor HTTP response or RequestId, and no user photos were sent. A Singapore comparison had an isolated success followed by failures, so changing region is not a verified correction. Diagnostic deployments have been removed and production networking remains unchanged.

We have supplied private measurements to the vendor and the Vercel support assistant. On our Hobby account, the support form does not allow a case under Vercel Functions or Secure Compute & Static IPs. Can a Vercel team member advise how to investigate destination-specific egress routing or filtering, and what minimal evidence should be collected after a concrete correction? We are not asking to bypass certificate validation or image moderation.

These are application observations, not packet captures. We have not established the actual source NAT address/port used toward the failed destination or identified the responsible network.

There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes.

https://community.vercel.com/t/debugging-404-errors/437

Vercel Community

Debugging 404 Errors

Sometimes things don’t go as expected when deploying a website. If you see a 404 on your site, that means the page or resource couldn’t be found. There are...

A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

Clarification for the human review: the HTTP 404 is from an intentionally unsigned GET and is our successful TCP/TLS reachability control, not the defect. The failing invocation never reaches TCP/TLS completion and receives no vendor HTTP response or RequestId. We need investigation of destination-specific outbound connectivity, not application routing or a missing deployment URL. No user photos or credentials are involved in these diagnostic measurements.

New diagnostic information (no production change): the vendor support team reports unexpected connectivity on the Hong Kong-to-Shanghai path and has suggested a Hong Kong endpoint comparison; no specific cause or correction has been provided. At 2026-10-10 02:58 UTC, one fresh hkg1 Node.js 22 invocation completed certificate-validated HTTPS to both green-cip.cn-shanghai.aliyuncs.com (377 ms) and green-cip.cn-hongkong.aliyuncs.com (247 ms), each with the expected unsigned GET 404. An independent HTTPS control returned 200. This is an intermittent, destination-specific connection issue: a successful invocation does not explain the earlier invocation where DNS resolved but neither fresh HTTPS POST nor GET completed TCP/TLS. We have not changed the production endpoint or moderation service.

Could a Vercel engineer advise how to correlate the actual destination-bound egress connection with vendor network records, or investigate the failing hkg1 connection path? These diagnostics used no photos or vendor credentials. We can coordinate a bounded sampling window. Project/deployment identifiers and IPs are intentionally omitted from this public thread.

Additional same-invocation reproduction at 2026-10-10 04:30 UTC, still hkg1 / Node.js 22: with the same existing signing implementation and credential configuration, a signed DescribeUploadToken request to green-cip.cn-shanghai.aliyuncs.com resolved DNS but did not complete TCP/TLS by a 15-second diagnostic cutoff. The subsequent request to green-cip.cn-hongkong.aliyuncs.com completed in 327 ms and returned HTTP 200 with valid token fields. Token values were not logged; no photos, image-moderation calls, service activation or purchases were involved. The production endpoint and permissions remain unchanged.

The vendor has clarified that cross-region public API calls have no explicit product restriction and has involved its network specialists. Their general explanation of cross-border public-network risks does not identify the specific failing segment. Could Vercel help correlate the actual Shanghai-bound egress connection and coordinate a sampling window with the vendor? We can provide project/deployment details through an appropriate private support channel, not this public thread. This paired result is diagnostic evidence, not a claim that the original photo path has been repaired.

A bounded mitigation test now succeeds while keeping the backend on Vercel hkg1. The vendor confirmed that its Singapore baseline image service includes the original baseline detection capabilities, and we matched the relevant enabled rules and thresholds. A protected full application candidate completed two new image uploads (about 4.2 s and 1.9 s), private save/read/download verification, and a same-ID retry without a duplicate. The vendor's Singapore result console corroborates these calls. All diagnostic images were repository-owned illustrations, with no user photos or credentials disclosed here.

Production has not been switched yet; final rule/account clarification is still pending. This is mitigation evidence, not proof that the original Shanghai-bound TCP/TLS failure was fixed. The vendor reports no product restriction on cross-region public requests but has not identified the exact failing public-network segment. We would still appreciate a Vercel engineer's guidance on correlating destination-bound egress with vendor records. The original bounded paired measurements above remain the relevant failure evidence.

Production update: after the vendor explicitly confirmed the remaining original detection scope, we deployed the image-only Singapore access adjustment while keeping the backend on Vercel hkg1 and retaining the moderation pass/reject requirements. Two fresh production image uploads returned HTTP 200 in about 3.2 s and 2.9 s. Private save, authorized read, byte-for-byte download, and a same-image-ID retry (about 2.6 s) passed; the retry created no duplicate. Unauthorized requests remained 401, and the private test data was cleaned up. No user photographs were used.

This restores the tested photo upload flow; it does not establish that the original Shanghai-bound connection failure is fixed. The vendor now says it cannot investigate the operator path further. If Vercel engineering can identify how to correlate destination-bound connection failures with its egress/network records, that original diagnosis would still be useful. We will not repeat the probes or change the working production path solely while waiting for a reply.

We are investigating intermittent connectivity from existing hkg1 Node.js 22 Functions to the public HTTPS endpoint green-cip.cn-shanghai.aliyuncs.com:443.

These are application observations, not packet captures. We have not established the actual source NAT address/port used toward the failed destination or identified the responsible network.