Feature Request: Optional Panel-to-Wings Request Proxy

[barkermn01]

Summary

Currently, many operations in the Pterodactyl Panel rely on the user's browser making direct AJAX/Fetch requests to the assigned Wings node. This requires the Wings API port (typically 8080) to be accessible from every client using the panel.

I would like to request an optional feature that allows these requests to be proxied through the Panel server instead of being made directly from the user's browser.

Use Case

In my environment, I would prefer to restrict access to Wings so that only the Panel server can communicate with it. However, because many panel functions currently perform direct browser-to-Wings requests, the Wings API must remain publicly accessible to all panel users.

The desired communication flow would be:

Browser
    ↓
Panel
    ↓
Wings

instead of:

Browser
    ↓
Wings

Benefits

• Allows Wings API ports to be firewall restricted so that only the Panel server can access them.
• Reduces the attack surface exposed to the public internet.
• Hides Wings endpoints and node IP addresses from end users.
• Simplifies firewall and network security configuration.
• Enables administrators to deploy Wings nodes behind stricter access controls without sacrificing functionality.
• Makes the Panel the only public-facing component of the Pterodactyl infrastructure.

Proposed Implementation

This could be implemented as an optional configuration setting, either globally or per-node, that instructs the Panel to proxy AJAX, Fetch, and WebSocket communications destined for Wings.

When enabled:

1. The browser sends requests to the Panel.
2. The Panel validates the user's permissions.
3. The Panel forwards the request to the appropriate Wings node.
4. The response is returned to the browser through the Panel.

Administrators who prefer the current architecture could leave the feature disabled, maintaining full backwards compatibility.

Security Considerations

This approach would allow administrators to configure firewall rules so that Wings only accepts connections from trusted Panel servers. In environments with strict security requirements, this would eliminate the need to expose the Wings API directly to end users.

The model is similar to how reverse proxies are commonly used to prevent direct access to backend services, allowing the Panel to act as the sole public-facing component while Wings remains an internal service.

Why This Matters

For self-hosted and enterprise deployments, reducing the number of publicly accessible services is a fundamental security best practice. An optional Panel-to-Wings proxy mode would provide administrators with greater control over their infrastructure while preserving the existing user experience.