In many projects we deploy applications that aren’t directly served by the main web server: Node.js SSR apps, websocket services, dashboards on ports other than 80/443, etc. To expose them cleanly under a domain (e.g. myapp.com) we place Apache in front as a reverse proxy.
What is a reverse proxy?
A reverse proxy retrieves resources on behalf of a client from one or more upstream servers and returns them as if they originated on the proxy itself. Typical use cases: load balancing, static/dynamic caching, security abstraction, centralised SSL termination and request routing.
SEO & performance benefits: faster perceived load (caching/compression) and stable TLS handling can improve Core Web Vitals. Security wise it lets you hide internal topology, enforce headers, rate‑limit or filter traffic.
Configuring Apache as reverse proxy
Enable required modules:
sudo a2enmod proxy
sudo a2enmod proxy_http
Create a virtual host (Debian path: /etc/apache2/sites-available/your-file.conf):
<VirtualHost *:80>
ServerName your-domain.com
ServerAlias www.your-domain.com
ProxyRequests Off
ProxyPreserveHost On
<Proxy *>
Require all granted
</Proxy>
ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
If you need the app under a sub‑path (e.g. /app) change / to /app on both ProxyPass directives and ensure the upstream app is aware of the base path.
Activate and restart:
sudo a2ensite your-file.conf
sudo service apache2 restart
Browse the domain to verify.
HTTPS
Create a parallel vhost on port 443 with valid SSL certificates (LetsEncrypt, commercial CA, etc.). Often you’ll also enable proxy_wstunnel for websockets and add security headers.
Conclusions
Using Apache as a reverse proxy for SSR or micro‑services centralises routing, boosts performance and adds a security layer. Mastering these basics streamlines multi‑stack deployments. Need help? Contact us.