Issue: External API connection timeout to api.stepfun.com based on request origin region

edward-roshan · July 20, 2026, 8:58am

Endpoint affected: POST /api/chat/ → calls api.stepfun.com/step_plan/v1/chat/completions

Behavior:

Request received in Hong Kong → Function invoked in Hong Kong → api.stepfun.com responds successfully
Request received in Singapore (sin1) → Function invoked in Hong Kong (hkg1) → api.stepfun.com times out

Error message:

ConnectTimeoutError: Connect Timeout Error (attempted address: api.stepfun.com:443, timeout: 10000ms)
code: 'UND_ERR_CONNECT_TIMEOUT'

Key details:

Same deployment, same function region (Hong Kong)
Only difference is where the request enters Vercel’s edge network
Suggests outbound network egress path differs based on the originating edge location

Expected behavior: External API connectivity from a function should be consistent regardless of which edge location received the initial request.

Request ID: gzzqm-1784536571259-f91ab552c0ac

ryux1 · July 21, 2026, 7:40pm

Hi Edward,

This is a good repro, but I’d separate “the function runs in hkg1” from “the outbound TCP path is identical.” Since the failure is UND_ERR_CONNECT_TIMEOUT, I’d first reduce it to a connectivity probe with no chat payload or provider logic.

You could add a temporary diagnostic route in the same project and region:

export const runtime = 'nodejs'
export const preferredRegion = 'hkg1'

export async function GET() {
  const started = Date.now()

  try {
    const res = await fetch('https://api.stepfun.com/', {
      method: 'HEAD',
      signal: AbortSignal.timeout(10000),
    })

    return Response.json({
      ok: true,
      status: res.status,
      region: process.env.VERCEL_REGION,
      ms: Date.now() - started,
    })
  } catch (err: any) {
    return Response.json(
      {
        ok: false,
        region: process.env.VERCEL_REGION,
        name: err?.name,
        code: err?.code,
        cause: err?.cause?.code,
        message: err?.message,
        ms: Date.now() - started,
      },
      { status: 500 }
    )
  }
}

A non-200 response from StepFun is still useful here, because it proves TCP/TLS/connectivity worked. The important failure case is another connect timeout.

Then hit that route from the two locations that produce different behavior and capture:

UTC timestamp
x-vercel-id
process.env.VERCEL_REGION
success/failure
error code/cause
elapsed time

If both requests report hkg1 but only the Singapore-entry request times out, that is stronger evidence for a network path/routing issue between Vercel and api.stepfun.com, rather than a Next.js route or payload problem.

One more control: try the same diagnostic route against a neutral HTTPS host like https://example.com/. If that works from both entry locations while only api.stepfun.com times out, the report becomes much more specific to that upstream destination.

weilueluo · July 21, 2026, 8:46pm

is this account supposed to use api.stepfun.com or .ai?

edward-roshan · July 22, 2026, 2:36am

Thank you for the help. The timeout only happened in routing from Singapore to Hongkong. If the call directly hit in Hongkong, the timeout won’t be happened.

edward-roshan · July 23, 2026, 3:36am

Request ID: jjvkn-1784777455444-c6406504e5f4

I have already added:

export const runtime = 'nodejs'
export const preferredRegion = 'hkg1'

But it’s still dispatch the request to the Tokyo, and routed to Hongkong. The issues are:

Chat API Error: [TypeError: fetch failed] {
[cause]: Error [ConnectTimeoutError]: Connect Timeout Error (attempted address: ``api.stepfun.com:443``, timeout: 10000ms)
at ignore-listed frames {
code: 'UND_ERR_CONNECT_TIMEOUT'
}
}

@ryux1 Can you please help for this? I setup region to Hongkong is only for best CDN connectivity for China mainland users.

edward-roshan · July 23, 2026, 4:21am

I got the feedback from stepfun.com. they separate the user into domestic and overseas. The access to stepfun from hongkong will have very high latency. Since the vercel won’t support China mainland nodes. I will think about how to migrate invocation into the domestic server. Thank you. This is not vercel side issue.

edward-roshan · July 23, 2026, 8:18am

Hi @ryux1 ,

I deployed the vercel function that you provided. https://wsbk.any-ape.com/api/admin/test/ , the response is:

{
“ok”: true,
“status”: 404,
“region”: “hkg1”,
“ms”: 938
}

the request sent from China mainland. it seems that it’s back to normal. I will contact stepfun to track the issue.

ryux1 · July 23, 2026, 12:10pm

Hi Edward,

Thanks for testing it. That response is actually a good sign:

{
  "ok": true,
  "status": 404,
  "region": "hkg1",
  "ms": 938
}

The 404 is fine for this diagnostic route because it still proves the outbound TCP/TLS connection to api.stepfun.com completed. The important part is that it did not hit UND_ERR_CONNECT_TIMEOUT, and region: "hkg1" confirms the function code ran in Hong Kong.

One small clarification: if you see Tokyo in the request path or x-vercel-id, that can be the edge/entry location for the incoming user request. It does not necessarily mean your Node.js function executed in Tokyo. For the function execution region, process.env.VERCEL_REGION from inside the function is the better signal.

Based on your latest test and StepFun’s feedback about domestic vs overseas access, I agree this does not look like a Vercel-side deployment issue anymore. I’d keep a small probe like this while talking to StepFun and log:

timestamp
region
status or error code
elapsed ms

If StepFun routes domestic and overseas traffic differently, moving the actual invocation to a domestic server or a StepFun-recommended endpoint sounds like the right direction.

edward-roshan · July 23, 2026, 1:02pm

Hi @ryux1 ,

It happened time to time. here is another failed request: 9gnmt-1784811411189-971492cc30f2

error occurs in the time below:
UTC July 23, 2026 12:56:51 PM

GMT+8 July 23, 2026 08:56:51 PM

edward-roshan · July 23, 2026, 1:22pm

This is request from Singapore to hongkong, it’s failed.

POST /api/chat/

Status: 500

Request

Started: Jul 23 21:16:56.40 GMT+8

Request ID: rf87j-1784812616400-0a1064eeee79

Path: /api/chat/

Host: wsbk.any-ape.com

User Agent: Mozilla/5.0 (Linux; Android 16; 23117RK66C Build/BP2A.250605.031.A3; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/150.0.7871.181 Mobile Safari/537.36 XWEB/1500047 MMWEBSDK/20260502 MMWEBID/4318 MicroMessenger/8.0.76.3141(0x28004C36) WeChat/arm64 Weixin NetType/WIFI Language/zh_CN ABI/arm64 MiniProgramEnv/android

Referer: https://servicewechat.com/wx7cc569d9394f8a67/33/page-frame.html

Received in Singapore (sin1)

Firewall

Log

Middleware

200

Execution Duration / Maximum: 12ms / 5m

External APIs

No outgoing requests

Fluid

254 MB

Routed to Hong Kong (hkg1)

Function Invocation

Route: / api / chat /

Execution Duration / Maximum: 10.51s / 5m

External APIs

External APIs

Method	Request
POST	Button: api.stepfun.com/step_plan/v1/chat/completions

Fluid

289 MB

Response finished in 11s

Deployment Information

Deployment ID: dpl_FNhPzakfFJcCcKCyvpsbAkxk64gK

Environment: production

This is request from USA to hongkong. it’s succeeded.

POST /api/chat/

Status: 200

Request

Started: Jul 23 21:18:32.42 GMT+8

Request ID: x46sm-1784812712423-1aed945398d7

Path: /api/chat/

Host: wsbk.any-ape.com

User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1 wechatdevtools/2.02.2607171 MicroMessenger/8.0.5 Language/zh_CN webview/ hash/2027782535 sid/s0 winId/s0 token/3c427a32815fbbf01473d64841e29a8f

Referer: https://servicewechat.com/wx7cc569d9394f8a67/devtools/page-frame.html

Received in San Francisco, USA (sfo1)

Firewall

Allowed

Middleware

200

Execution Duration / Maximum: 98ms / 5m

External APIs

Fluid

253 MB

Routed to Hong Kong (hkg1)

Function Invocation

Route: / api / chat /

Execution Duration / Maximum: 8.30s / 5m

External APIs

External APIs

Method	Request
POST	Button: api.stepfun.com/step_plan/v1/chat/completions

Fluid

273 MB

Response finished in 9s

Deployment Information

Deployment ID: dpl_FNhPzakfFJcCcKCyvpsbAkxk64gK

Environment: production

WHY???

edward-roshan · July 23, 2026, 1:25pm

This one is Singapore to Hongkong: l2x55-1784813051088-bead5170dba0

But it’s worked. Maybe the reason is just slow response from stepfun.

ryux1 · July 23, 2026, 1:40pm

Hi Edward,

The two logs are useful, but I’d be careful with the conclusion from “Received in Singapore” vs “Received in San Francisco”.

In both examples, the important line is:

Routed to Hong Kong (hkg1)

That means your function invocation is still running in Hong Kong. The sin1 / sfo1 part is the incoming edge location that received the user request before it was routed to the function.

So if both requests run in hkg1, but one outbound request to StepFun times out and another succeeds, I’d treat this as intermittent connectivity or StepFun-side routing from the Hong Kong function environment, not proof that the function is executing in Singapore.

One thing I’d add to the diagnostic route is the exact same StepFun endpoint path your app uses, not just https://api.stepfun.com/, because the root HEAD returning 404 only proves basic TCP/TLS works:

https://api.stepfun.com/step_plan/v1/chat/completions

Log only non-secret fields:

UTC timestamp
Vercel request ID
process.env.VERCEL_REGION
StepFun endpoint path
success/failure
error name/code/cause
elapsed ms

The failed request is very useful evidence:

Request ID: rf87j-1784812616400-0a1064eeee79
Received in: sin1
Function region: hkg1
Error: UND_ERR_CONNECT_TIMEOUT after ~10s

But I would compare it with several more requests before assuming the incoming edge is the cause. If all failures still run in hkg1, and StepFun already said Hong Kong access can have high latency for overseas routing, then the most likely fix is still on the StepFun endpoint/routing side or moving that provider call to the domestic server path they recommend.

edward-roshan · July 23, 2026, 2:01pm

Yes. The conclusion is:

Not all of requests failed in HongKong region.
It’s connectivity issue. not slow response from stepfun.
vercel function in hongkong have intermittent connectivity issue to stepfun.

I have alreay sent the post link to stepfun ticket support. Hope they can deep into the issue to figure it out. Let me wait their reply tomorrow. Do you have any more information which can provide to stepfun? so that they can check the routing nodes from vercel hongkong function to stepfun domestic server. they just said, their AI model deployed in Shanghai. Shanghai to hongkong won’t be so slow.

edward-roshan · July 24, 2026, 2:37am

Hi Ryu,

I use GLM-5.2 to sniff the network between Vercel and Stepfun. It says stepfun deployed to Volcengine and setup WAF(web application firewall) infront of web app. I suppose the request hit the WAF policy, and intermittent cutoff the connection to the stepfun. The WAF sometimes will sniff the request that sent from AWS DC hongkong server(overseas) to the stepfun application server. Maybe It’s reason for regulatory and compliance policy.

As a Chinese, that’s so funny that cloud provider treat Hongkong as overseas place. If someone bought stepfun coding plan, the invocation is working. but when he come to hongkong, it’s broken time to time. The issue gradually loud and clear. I think the best way is shut down this function for my app. It only have very few invocation. And my users suspect the app tracking their privacy.

AI can do everything, but AI can’t fix geo-political conflict. That is so ironic.

ryux1 · July 24, 2026, 2:46am

Hi Edward,

That makes sense, but I’d treat the WAF/Volcengine explanation as a hypothesis until StepFun confirms it from their own logs.

For StepFun, I’d send a compact report like this:

Vercel function region: hkg1
Endpoint: api.stepfun.com/step_plan/v1/chat/completions
Failure type: UND_ERR_CONNECT_TIMEOUT before response
Timeout: ~10s
Failed Vercel request IDs:
- rf87j-1784812616400-0a1064eeee79
- 9gnmt-1784811411189-971492cc30f2

Successful request ID from same hkg1 function:
- x46sm-1784812712423-1aed945398d7

Question for StepFun:
Can you check whether requests from Vercel Hong Kong / overseas cloud egress are being blocked, rate-limited, challenged, or dropped by WAF/load-balancer policy before reaching the Shanghai model service?

If you add DNS logging like this:

import { resolve4 } from "node:dns/promises"

const ips = await resolve4("api.stepfun.com")
console.log({
  region: process.env.VERCEL_REGION,
  stepfunResolvedIps: ips,
})

then StepFun can also compare whether failed and successful calls resolve to different upstream IPs.

I would not rely on allowlisting a single source IP unless you are using a static egress setup, because normal serverless outbound IPs may not be something you can treat as fixed.

For the product decision, disabling the feature sounds reasonable if it has low usage and users are concerned about privacy. If you keep it later, I’d put it behind a clear opt-in or feature flag and route the StepFun call through an environment StepFun explicitly supports for mainland/domestic access.

edward-roshan · July 24, 2026, 3:01am

Ryu:

Can you check whether requests from Vercel Hong Kong / overseas cloud egress are being blocked, rate-limited, challenged, or dropped by WAF/load-balancer policy before reaching the Shanghai model service?

I have already leave this post link to their support ticket. They should might know the loop. They might not necessarily cooperate for search WAF logs for me. Anyway, they just only put conclusion is overseas invocation to use overseas endpoint. They only reply to me right before getting off work. Let’s just wait. I don’t think i spend money to let my app user use AI function but without any income from it is a good choice.

edward-roshan · July 29, 2026, 7:50am

Hi @ryux1 ,

Stepfun side didn’t give me any further topic about WAF. they just said they didn’t receive timeout request. They also give me some overseas platform budget for testing. Currently, the function is running well.

I have another question for AI invocation from vercel. The AI gateway section. I can “Bring my own key”, and setup my API Key to the gateway. I want to know about the baseUrl usage of AI gateway.

For China mainland, the baseUrl should use “https://api.stepfun.com”. For overseas, the baseUrl should use “https://api.stepfun.ai”. Can you confirm that for me? or just let me invoke directly. I have domestic and overseas accounts. and I also have budget for testing.

ryux1 · July 29, 2026, 6:35pm

Hi Edward,

Good update. If the overseas platform is working now, I’d treat StepFun’s “use the overseas endpoint for overseas invocation” as the most reliable rule for direct calls.

For direct StepFun calls, yes, I would separate them like this:

China mainland / domestic StepFun account:
https://api.stepfun.com/step_plan/v1

Overseas / international StepFun account:
https://api.stepfun.ai/step_plan/v1

So for the OpenAI-compatible chat completions path, that becomes:

https://api.stepfun.com/step_plan/v1/chat/completions
https://api.stepfun.ai/step_plan/v1/chat/completions

For Vercel AI Gateway, I would think about it differently: your app’s baseURL should be the AI Gateway endpoint, not StepFun’s endpoint directly:

https://ai-gateway.vercel.sh/v1

Then you call the StepFun model through the Gateway model ID, using your AI Gateway key. BYOK means Gateway can use your provider credentials, but I would not assume you can choose api.stepfun.com vs api.stepfun.ai as the upstream route unless the Gateway UI/docs expose that option for StepFun specifically.

So my practical recommendation would be:

Need strict China/overseas endpoint control?
→ Call StepFun directly and choose .com or .ai yourself.

Want unified logging, budgets, model routing, and Gateway behavior?
→ Use Vercel AI Gateway, but test whether its StepFun route matches your region/compliance needs.

I’d run both paths with the same prompt and log only non-sensitive fields:

provider: direct-stepfun-cn / direct-stepfun-overseas / vercel-ai-gateway
vercel region: process.env.VERCEL_REGION
status code
latency
error type
request timestamp

If direct api.stepfun.ai works from Vercel but Gateway has a different failure pattern, then it’s a Gateway/provider-routing question. If Gateway works consistently, it may be the cleaner option for observability and budgets.

edward-roshan · July 30, 2026, 2:32am

Hi @ryux1 ,

I use overseas Stepfun baseUrl directly in my app. I don’t use AI gateway to integrate Stepfun AI. After I change to api.stepfun.ai. The connection timeout no happened again.

I don’t know if there is a Vercel official staff can check AI gateway failure log. If WAF make connection fail, other AI gateway users who setup stepfun as there usage model will meet failure requests.

I have some proposals for vercel:

Check AI Gateway stepfun model baseUrl usage. and provide cn and overseas options for invokers. Or just change to Overseas baseUrl.(because Vercel don’t have nodes in China mainland)
Stepfun released their overseas platform in recent month. So tracking other AI gateway stepfun usage logs can easily to tracking the accurate reason the connection timeout issue.

Topic		Replies	Views
Vercel projects inaccessible with timeout errors on Hobby plan in Brazil Help domains , account , monitoring , cdn	14	274	February 26, 2026
Serverless Egress Network Block (TCP Handshake Timeout) in ALL Regions Help firewall , queues	0	47	November 28, 2025
Timeout errors on new deployments 504 Help	6	306	September 25, 2024
Urgent: Payment Fraud Block (UA/RO) & Edge Function 504 Timeout issue Help	2	66	February 12, 2026
Function error Help	9	109	April 26, 2025

Issue: External API connection timeout to api.stepfun.com based on request origin region

POST /api/chat/

Request

Firewall

Middleware

External APIs

Fluid

Function Invocation

External APIs

Fluid

Deployment Information

POST /api/chat/

Request

Firewall

Middleware

External APIs

Fluid

Function Invocation

External APIs

Fluid

Deployment Information

Related topics