Project: [remarkable-laughter]

Service: frontend (Node.js / Next.js, Railpack builder)

Affected deployments: 241445cb (region: Southeast Asia/Singapore), a2d40bc4 (region: US East/Virginia)

Issue:

Every build of this service fails during the install phase. The build logs show npm attempting to fetch packages from http://mirrors.tencentyun.com/npm/... (a Tencent Cloud China npm mirror) instead of the default npm registry, e.g.:

npm http fetch GET http://mirrors.tencentyun.com/npm/next/-/next-16.2.12.tgz attempt 6 failed with ENOTFOUND

npm http fetch GET http://mirrors.tencentyun.com/npm/postcss/-/postcss-8.5.23.tgz attempt 6 failed with ENOTFOUND

Every fetch fails with ENOTFOUND after 6 retries, the step hangs for ~4 minutes, and the build ultimately fails with npm's own internal error:

npm error Exit handler never called!

npm error This is an error with npm itself.

What we've confirmed is NOT the cause:

No .npmrc file exists anywhere in the repository (checked via git ls-tree).

Not a lockfile/dependency-resolution issue — npm ci against the exact committed package.json/package-lock.json succeeds cleanly on our own machines in ~7 seconds.

What we've already tried, in increasing order of npm's own config precedence — all failed with the identical Tencent mirror requests:

Set NPM_CONFIG_REGISTRY=https://registry.npmjs.org as a service Variable.

Set RAILPACK_INSTALL_CMD=npm install --loglevel verbose --registry=https://registry.npmjs.org (an explicit CLI flag, which per npm's own documented precedence rules should override every other config source, including any environment variable).

Changed the service's deploy region from Southeast Asia (Singapore) to US East (Virginia) — identical failure, ruling out a region-specific default.

Since even an explicit --registry CLI flag doesn't change which host npm actually contacts, this doesn't look like something we can fix from application-level npm config — it looks like something in the Railpack/Railway build pipeline itself (e.g. an internal dependency cache/proxy) is forcing package fetches through this Tencent Cloud mirror regardless of the project's own npm configuration.

Ask: Could you investigate why this service's build is routing package downloads through mirrors.tencentyun.com, and why that isn't overridable via standard npm config channels?