Hello,
I’d like to submit a feature request regarding Web Page connections on RoyalTSX for macOS when using a Secure Gateway as a proxy server.
Current Behavior (macOS)
When a Web Page connection is configured with:
- Use Dedicated Engine: enabled
- Proxy: Use Secure Gateway as proxy server
RoyalTSX on macOS creates a local TCP tunnel and redirects the browser to https://127.0.0.1:. As a result, the HTTP Host header sent to the destination server contains “127.0.0.1” instead of the original hostname.
Expected / Windows Behavior
On Windows, the same configuration works correctly — the browser navigates to the original URL, and the Host header is preserved, allowing the destination server to correctly identify and route the request.
Impact
Many modern cloud-hosted applications rely on ingress controllers (e.g., Kubernetes NGINX Ingress, AWS ALB, Azure Application Gateway) that use Host header-based routing rules. When the Host header is “127.0.0.1”, these ingress rules do not match and the server returns a 404 error. This makes the Web Page connection type non-functional on macOS for this common infrastructure pattern, even though the same configuration works perfectly on Windows.
Feature Request
We would like to request one or more of the following improvements:
-
Preserve the original Host header — When the dedicated engine on macOS establishes a tunnel via Secure Gateway, the browser should still navigate to the original hostname (e.g., https://your-app.example.com), so that the correct Host header is sent.
-
Add an “Effective URL” / “Browser URL” field — A separate setting that allows users to specify the URL the browser should navigate to, independently of the tunnel endpoint. This would give administrators full control over the Host header.
-
Consistent cross-platform behavior — Ideally, the macOS behavior should match Windows, where the original URL and Host header are preserved end-to-end.
Environment
- Platform: macOS
- Application: RoyalTSX
- Connection type: Web Page
- Proxy: Secure Gateway
- Dedicated Engine: enabled
This is a blocking issue for teams managing cloud-hosted applications behind hostname-based ingress rules. We would greatly appreciate this being considered for an upcoming release.
Best regards,
Pavels