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

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.

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.

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.

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.

Hi Edward,

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

1{2  "ok": true,3  "status": 404,4  "region": "hkg1",5  "ms": 9386}7

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:

1timestamp2region3status or error code4elapsed ms5

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.

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

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

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

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:

1Routed to Hong Kong (hkg1)2

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:

1https://api.stepfun.com/step_plan/v1/chat/completions2

Log only non-secret fields:

1UTC timestamp2Vercel request ID3process.env.VERCEL_REGION4StepFun endpoint path5success/failure6error name/code/cause7elapsed ms8

The failed request is very useful evidence:

1Request ID: rf87j-1784812616400-0a1064eeee792Received in: sin13Function region: hkg14Error: UND_ERR_CONNECT_TIMEOUT after ~10s5

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.

Yes. The conclusion is:

1. Not all of requests failed in HongKong region.
2. It's connectivity issue. not slow response from stepfun.
3. 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.

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.

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:

1Vercel function region: hkg12Endpoint: api.stepfun.com/step_plan/v1/chat/completions3Failure type: UND_ERR_CONNECT_TIMEOUT before response4Timeout: ~10s5Failed Vercel request IDs:6- rf87j-1784812616400-0a1064eeee797- 9gnmt-1784811411189-971492cc30f289Successful request ID from same hkg1 function:10- x46sm-1784812712423-1aed945398d71112Question for StepFun:13Can 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?14

If you add DNS logging like this:

1import { resolve4 } from "node:dns/promises"23const ips = await resolve4("api.stepfun.com")4console.log({5  region: process.env.VERCEL_REGION,6  stepfunResolvedIps: ips,7})8

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.

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.

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.

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:

1China mainland / domestic StepFun account:2https://api.stepfun.com/step_plan/v134Overseas / international StepFun account:5https://api.stepfun.ai/step_plan/v16

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

1https://api.stepfun.com/step_plan/v1/chat/completions2https://api.stepfun.ai/step_plan/v1/chat/completions3

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:

1https://ai-gateway.vercel.sh/v12

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:

1Need strict China/overseas endpoint control?2→ Call StepFun directly and choose .com or .ai yourself.34Want unified logging, budgets, model routing, and Gateway behavior?5→ Use Vercel AI Gateway, but test whether its StepFun route matches your region/compliance needs.6

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

1provider: direct-stepfun-cn / direct-stepfun-overseas / vercel-ai-gateway2vercel region: process.env.VERCEL_REGION3status code4latency5error type6request timestamp7

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.

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:

1. 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)

2. 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.