Skip to content

fix: use absolute backend URL in tauri production mode (welcome page stuck on 'Loading Failed') - #307

Merged
MistEO merged 5 commits into
MistEO:mainfrom
zhuohoudeputao:fix/backend-api-base-tauri
Aug 5, 2026
Merged

fix: use absolute backend URL in tauri production mode (welcome page stuck on 'Loading Failed')#307
MistEO merged 5 commits into
MistEO:mainfrom
zhuohoudeputao:fix/backend-api-base-tauri

Conversation

@zhuohoudeputao

@zhuohoudeputao zhuohoudeputao commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

问题 / Problem

On Linux (Arch + Hyprland, tauri webview), the welcome page is stuck on a "Loading Failed / 加载失败" error dialog and the main UI is unreachable. Reported as MaaEnd/MaaEnd#4692.

Root cause: getApiBase() returns the relative path /api whenever window.location.host is truthy — which is always the case under tauri://localhost. In tauri production the webview cannot reach /api (tauri does not proxy it to the axum web server), so the interface fetch fails and content loading (DESCRIPTION.md etc.) falls back to showing the raw path with the error dialog.

修复 / Fix

  • getApiBase(): once the backend port has been discovered via setBackendPort(), prefer the absolute http://host:port/api URL. The relative /api path remains as a dev-mode (Vite proxy) / same-origin reverse-proxy fallback.
  • getWsUrl(): same fix for the WebSocket endpoint (serverPort already exists).

Verified: pnpm build passes; the compiled getApiBase now returns the absolute URL when the backend port is known.

验证 / Verification

  • Backend API on port 12701 responds correctly (curl http://127.0.0.1:12701/api/interface and /api/local-file?path=... both return 200).
  • The bug is that the frontend never uses that port because the relative /api path resolves under tauri://localhost and returns the embedded index.html (SPA fallback) instead of JSON.
  • After this fix, once the port-probe succeeds, all subsequent API calls go to http://localhost:12701/api/... which works.

Summary by Sourcery

确保在探测到后端端口可用时,前端使用绝对后端 URL,以修复 Tauri 生产模式下的 API 加载失败问题。

New Features:

  • 当已发现后端端口时,支持通过绝对 http URL 直接连接到后端。

Bug Fixes:

  • 通过避免在 Tauri 生产模式下无法访问的相对 /api 请求,修复欢迎页加载失败的问题。
  • 当已知后端服务器端口时,通过优先使用绝对 ws URL 修复 WebSocket 连接问题。

Enhancements:

  • 优化后端 URL 选择逻辑,更好地区分开发模式下使用代理与直接访问后端的路径。
Original summary in English

Summary by Sourcery

Ensure frontend uses an absolute backend URL when a probed backend port is available to fix API loading failures in Tauri production mode.

New Features:

  • Support direct connections to the backend via an absolute http URL when the backend port has been discovered.

Bug Fixes:

  • Fix welcome page failing to load by avoiding relative /api requests that are unreachable in Tauri production mode.
  • Fix WebSocket connections by preferring an absolute ws URL when the backend server port is known.

Enhancements:

  • Refine backend URL selection logic to better distinguish between dev-mode proxy usage and direct backend access paths.

getApiBase() returned relative '/api' whenever window.location.host was
truthy, which is always the case under tauri://localhost. In tauri
production the webview cannot reach '/api' (tauri does not proxy it to
the axum web server), so interface loading failed with '加载失败'
(welcome page stuck) on Linux.

Fix: once the backend port has been discovered (setBackendPort), prefer
the absolute http://host:port/api URL. The relative path remains as a
dev-mode (Vite proxy) fallback. Same fix applied to getWsUrl() for the
WebSocket endpoint.

Fixes MaaEnd/MaaEnd#4692 (reported against MaaEnd v2.22.0 on Arch Linux
+ Hyprland, tauri webview stuck on welcome page 'Loading Failed').

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - 我在这里给出了一些总体反馈:

  • getApiBasegetWsUrl 中用于推导协议/主机名的逻辑是重复的,并且与 Nginx/host 分支存在一些差异;建议把 URL 构建集中到一个辅助方法中,以保持行为一致并更易于维护。
  • getApiBase 中,backendPort > 0 分支即使在同源反向代理后面运行时,也会始终优先选择直连 URL;如果这是刻意设计的,可能值得显式防范 hostname 与后端绑定不匹配的情况(例如,当探测到的端口只监听在 localhost 时强制使用 localhost)。
给 AI Agent 的提示
请根据这次代码评审中的评论进行修改:

## 总体评论
-`getApiBase``getWsUrl` 中用于推导协议/主机名的逻辑是重复的,并且与 Nginx/host 分支存在一些差异;建议把 URL 构建集中到一个辅助方法中,以保持行为一致并更易于维护。
-`getApiBase` 中,`backendPort > 0` 分支即使在同源反向代理后面运行时,也会始终优先选择直连 URL;如果这是刻意设计的,可能值得显式防范 `hostname` 与后端绑定不匹配的情况(例如,当探测到的端口只监听在 localhost 时强制使用 `localhost`)。

Sourcery 对开源项目免费——如果你觉得我们的评审有帮助,欢迎分享 ✨
帮我变得更有用!请在每条评论上点击 👍 或 👎,我会根据你的反馈改进后续评审。
Original comment in English

Hey - I've left some high level feedback:

  • The logic for deriving protocol/hostname in both getApiBase and getWsUrl is duplicated and slightly different from the Nginx/host branch; consider centralizing URL construction in a helper to keep behavior consistent and easier to maintain.
  • In getApiBase, the backendPort > 0 branch always prefers a direct URL even when running behind a same-origin reverse proxy; if that’s intentional, it may be worth explicitly guarding against mismatched hostname/backend binding (e.g., forcing localhost when the probed port only listens there).
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The logic for deriving protocol/hostname in both `getApiBase` and `getWsUrl` is duplicated and slightly different from the Nginx/host branch; consider centralizing URL construction in a helper to keep behavior consistent and easier to maintain.
- In `getApiBase`, the `backendPort > 0` branch always prefers a direct URL even when running behind a same-origin reverse proxy; if that’s intentional, it may be worth explicitly guarding against mismatched `hostname`/backend binding (e.g., forcing `localhost` when the probed port only listens there).

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

In tauri mode, interface.json loads via invoke (successful), but all
subsequent API calls (getApiBase()/config, /background-image,
/local-file) went to the relative /api path because backendPort was
never set in the tauri branch — only the browser-env port probe sets
it. Under tauri://localhost the relative /api resolves to a
non-existent endpoint -> 'Could not connect to localhost'.

Set backendPort from the actual web server port (invoke
get_web_server_port) in the tauri branch, falling back to 12701.
In tauri production the frontend is served from tauri://localhost
(embedded assets) but fetches the axum backend at http://127.0.0.1:12701
— a cross-origin request. The production CorsLayer omitted allow_origin,
so the browser blocked every API call, surfacing as 'Could not connect
to localhost: Connection refused'. Match the debug config (allow_origin
Any + allow_headers Any).
get_web_server_port returns 0 (no error) when the web server is not yet
bound or disabled. The previous fix only set backendPort when port > 0,
so backendPort stayed 0 during startup races and getApiBase() fell back
to the relative /api path. Set backendPort unconditionally, defaulting
to 12701.
@MistEO
MistEO merged commit 6ef18b0 into MistEO:main Aug 5, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants