Link to the code that reproduces this issue

https://github.com/blakel6819/nextjs-server-action-external-redirect

To Reproduce

1. Run the repro repo on port 3000
2. Navigate to http://localhost:3000/redirect/external
3. Wait 10 seconds for useEffect to run and redirect to http://localhost:3000/external-page-with-same-host

Current vs. Expected behavior

Following the steps from the previous section, I expected to be redirected to 404 error page with URL http://localhost:3000/external-page-with-same-host, but was redirected to a 404 error page with the URL http://localhost:3000/redirect/external-page-with-same-host that contains the basePath defined in next.config.ts.

NOTE: This will only occur the first time the page is loaded, after that the redirect works as expected.

Expected Redirected to 404 error page with URL http://localhost:3000/external-page-with-same-host.

Actual Redirected to 404 error page with URL http://localhost:3000/redirect/external-page-with-same-host.

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Enterprise
  Available memory (MB): 65167
  Available CPU cores: 22
Binaries:
  Node: 24.6.0
  npm: 11.5.1
  Yarn: N/A
  pnpm: 10.10.0
Relevant Packages:
  next: 16.1.0
  eslint-config-next: 16.1.0
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: standalone
  basePath: /redirect

Which area(s) are affected? (Select all that apply)

Server Actions, Redirects

Which stage(s) are affected? (Select all that apply)

Other (Deployed), next dev (local)

Additional context

This functionality worked prior to v16.1.0 (which can be validated by changing the version of next to v16.0.10 in the repro repo and running the steps to reproduce).

The issue occurs locally and when deployed (I have not tested on a Vercel deployment, only on an Azure Container App deployment).

The exact canary version that the issue was introduced is v16.1.0-canary.17 in and can confirm the issue doesn't occur if v16.1.0-canary.16 is installed.

This pull request might be the point where the issue was introduced, but I cannot confirm. This pull request was raised about a month later to address an issue introduced in the previous pull request, but did not resolve the issue I am raising. This pull request was raised about a month later to address this issue that seemed very similar to the issue that I am raising, but I have tested the v16.1.1-canary.18 canary build on the repro repo and the issue still occurs.

• I have also tested on the latest canary build v16.2.0-canary.26 on the repro repo and the issue still occurs.