I’m working on setting up a reverse proxy using Apache to access Figma design prototypes through my own domain that has SSL certificates configured. The basic Figma homepage proxying works fine, but I’m having trouble getting the actual prototype pages to load properly.
I want to access a specific Figma prototype page through my custom domain. The main Figma site proxies correctly with my current setup, but when I try to reach the prototype section, it just shows a loading screen and never actually loads the prototype content.
Here’s my current Apache configuration that works for the main Figma site:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
SSLUseStapling on
ServerName mydomain.com
DocumentRoot /var/www/mydomain
ProxyRequests Off
SSLProxyEngine On
ProxyPreserveHost Off
ProxyPass / https://www.figma.com/
ProxyPassReverse / https://www.figma.com/
SSLEngine on
SSLCertificateKeyFile server.key
SSLCertificateFile server.crt
SSLCertificateChainFile server.ca-bundle
</VirtualHost>
</IfModule>
I suspect the issue is related to WebSocket connections that Figma prototypes use. I tried enabling mod_proxy_wstunnel and added these rewrite rules:
But this approach didn’t work either. I’m not sure if it’s possible to properly configure WebSocket proxying to an external service like Figma since I don’t have access to their WebSocket port configurations. Has anyone successfully set up a reverse proxy for Figma prototypes that handles the WebSocket connections properly?
been fighting this websocket nightmare for weeks too. figma’s prototype viewer uses multiple ws endpoints that get generated on the fly, so static ProxyPass rules won’t catch them all. add ProxyPassReverse entries for websockets - most people forget that part. figma also does weird CORS stuff, so throw Header always set Access-Control-Allow-Origin "*" in your vhost. honestly though, figma’s infrastructure is pretty locked down and might not work with external proxies no matter what you try.
Your WebSocket setup needs a different approach. The problem isn’t just enabling mod_proxy_wstunnel - it’s how you’re handling the protocol upgrade. Ditch those RewriteRule directives and use ProxyPassMatch with the upgrade parameter instead. Try ProxyPassMatch "^/(.*)" "https://www.figma.com/$1" upgrade=websocket - this tells Apache to handle protocol upgrades automatically. You’ll also need ProxyAddHeaders On so the Upgrade and Connection headers get passed through correctly. That persistent loading screen means the WebSocket handshake is completely failing, not just timing out. I got it working by adding ProxyPass /api/websocket/ wss://www.figma.com/api/websocket/ specifically for Figma’s WebSocket endpoints - they use predictable paths for some connections. But here’s the catch: Figma has some pretty aggressive anti-proxying measures, including JavaScript-based origin checks that run after the WebSocket connects. Even with perfect Apache config, you might still hit issues with their client-side validation blocking your domain.
WebSocket handling is your bottleneck. I hit the same issue proxying real-time apps through Apache. Don’t use RewriteRule for WebSocket upgrades - set up dedicated ProxyPass directives for WebSocket endpoints before your general proxy rules. Add ProxyPass /socket.io/ wss://www.figma.com/socket.io/ and ProxyPass /ws/ wss://www.figma.com/ws/ above your main ProxyPass line. Order matters since Apache processes top to bottom. Make sure you’ve enabled mod_proxy_http and mod_proxy_wstunnel modules. That persistent loading screen means the WebSocket handshake is completely failing, not just timing out. What helped me was adding ProxyPreserveHost On instead of Off - some apps validate the Host header during WebSocket upgrade. You might need to tweak your ProxyTimeout and add retry=0 to your ProxyPass directives so Apache doesn’t mark WebSocket endpoints as down when connections close normally.
I’ve dealt with this exact issue proxying Figma through Apache. Your WebSocket config is close, but needs some tweaks. Your RewriteRule should use ws:// or wss:// in the substitution while keeping the [P,L] flags. The real problem is Figma’s prototypes depend heavily on WebSocket connections for real-time updates, and they do origin checks that’ll fail when proxied through your domain. You need ProxyPassMatch directives for WebSocket endpoints specifically. Try ProxyPassMatch "^/ws/(.*)" "wss://www.figma.com/ws/$1" and make sure your SSL proxy settings include SSLProxyCheckPeerName off for certificate validation. You’ll probably also need to modify response headers for CORS issues since your origin domain won’t match what Figma expects. Fair warning though - even with proper WebSocket proxying, some Figma features might still break because of their client-side origin validation.
This happens because Figma uses dynamic WebSocket endpoints and has strict security policies. I’ve hit similar issues proxying other real-time apps through Apache. Your setup isn’t handling WebSocket upgrades properly - that’s what Figma prototypes need. Don’t use RewriteRule for WebSocket connections. Instead, configure Apache to handle the upgrade protocol directly with ProxyPass / and upgrade=websocket. Add these to your config: SetEnvIf Upgrade websocket upgrade_requested and ProxyPassMatch “^/(.*)” “https://www.figma.com/$1” upgrade=any. You’re probably missing the Connection: upgrade header handling - that’s usually the culprit. Also set ProxyTimeout 0 for WebSocket connections so they don’t timeout early. Fair warning though: Figma does client-side domain validation that might block external proxying no matter how you configure Apache. I’d test with simpler WebSocket apps first to make sure your proxy works before blaming Figma.