Download Links Redirect to 127.0.0.1 When Using a Public Gateway with Reverse Proxy

[arisumimi]

Describe the bug
A clear and concise description of what the bug is.

When configuring Kubo to serve a public gateway behind a reverse proxy (tested with Nginx and Caddy), the download links generated by the WebUI and the gateway continue to redirect to http://127.0.0.1:8080/... instead of using the public domain.

This completely breaks the ability for external users to download files via WebUI or direct links.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'a file on the webui'
2. Click on 'the download button'
3. See error

Expected behavior
When using Kubo behind a reverse proxy (such as Nginx or Caddy) with a properly configured public gateway, all generated URLs including download links and redirects from the WebUI or API should consistently use the public domain (e.g., https://ipfs.alicepantsu.moe) instead of the local address (http://127.0.0.1:8080).

Specifically:

The Location header in HTTP responses should point to the public gateway domain.

The WebUI should generate download links that respect the public proxy address, making them accessible to external users.

No hardcoded redirects to 127.0.0.1 should occur when accessing files or clicking the "download" button.

This would allow seamless external access to IPFS content via the public gateway without manual header rewriting or fragile reverse proxy tricks.

Desktop (please complete the following information):

• OS: Windows
• Browser Chrome
• Version 137.0.7151.120

Additional context

Gateway Configuration Used:

"PublicGateways": {
"ipfs.alicepantsu.moe": {
"NoDNSLink": false,
"Paths": ["/ipfs", "/ipns"],
"UseSubdomains": false
}
},
"HTTPHeaders": {
"Access-Control-Allow-Origin": [
"https://ipfs.alicepantsu.moe",
"http://localhost:3000",
"http://127.0.0.1:5001",
"https://webui.ipfs.io"
],
"Access-Control-Allow-Methods": ["PUT", "POST"]
}

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.tech if you just need general support.