This is an infrastructure setup, not a Yuri settings page. Begin with a host that works directly. Record its actual address and port before adding a proxy.
Preserve the connection's behavior
Forward the application and API paths consistently, including authentication. Preserve the host and forwarded-protocol information needed for the public origin. Support WebSocket upgrades and long-lived streams; do not buffer SSE into a response that appears only when the request ends.
Examples of long-lived paths include /api/event/ws, /api/global/event/ws, /api/terminal/ws, /api/yuri/events and /api/notifications/stream. Do not treat this list as an exhaustive allowlist: speech and other capabilities have their own endpoints.
Set upload limits for the files you intend to send, and idle timeouts for interactive sessions. Configure compression deliberately across the host and proxy rather than layering assumptions from an unrelated example.
Test four real interactions
- Sign in through the public HTTPS address and reload it.
- Send a request and confirm that progress arrives while work is running.
- Open a terminal, then send a representative attachment.
- Reconnect after briefly losing the client network.
If direct access succeeds and only proxied access fails, inspect the proxy's upstream status, upgrade handling, buffering and size limits. If both fail, return to host troubleshooting before changing the proxy.