Recommended Free Tools
For a small VPS, the safest starting point is to cache only public GET and HEAD responses, then bypass the cache whenever a request is authenticated, session-specific, or otherwise personalized. Use proxy_cache for an HTTP application server and fastcgi_cache for PHP or another FastCGI application. Add cache locking to prevent a burst of misses from overwhelming the origin, configure upstream keepalive correctly, and enable compression only when its CPU cost fits the machine.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
There is no universal percentage improvement to expect. The result depends on the application, cache-hit rate, disk, memory, CPU, and request mix. Measure your own VPS before and after each change.
As an Amazon Associate I earn from qualifying purchases.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhat NGINX caching does on a VPS
When caching is enabled, NGINX stores reusable upstream responses on disk and can serve later identical requests without contacting the application for every visitor. The shared-memory zone tracks cache keys and metadata, while the response body is stored in the cache directory. This can protect a small game-news site, forum landing page, or API-backed front end from repeated reads and application work.
Caching is not the same as making every page static. NGINX still has to decide whether a request is eligible, calculate its key, check expiry, and send the result. A cache is useful only when many requests can safely receive the same representation. Public article pages, image metadata, patch-note pages, and other read-only resources are common candidates. A logged-in profile, shopping basket, moderation screen, or personalized game dashboard normally is not.
#1 Best Overall
Choose the module that matches the upstream
| Question | Use proxy caching when… | Use FastCGI caching when… |
|---|---|---|
| Application protocol | NGINX forwards HTTP to an application server such as a Node, Python, Ruby, or Go service. | NGINX sends requests through FastCGI, commonly to PHP-FPM. |
| Configuration directives | proxy_cache_path, proxy_cache, proxy_cache_valid, and related proxy directives. |
fastcgi_cache_path, fastcgi_cache, fastcgi_cache_valid, and related FastCGI directives. |
| Cache key | Define a key that includes the scheme, method, host, and URI, plus any query data that changes the response. | Define a key that includes the scheme, method, host, and URI, plus every input that changes the FastCGI response. |
| Personalization | Bypass on authorization and session cookies; do not store responses that set cookies. | Use the same safeguards, with FastCGI-specific bypass and no-cache directives. |
| Invalidation | Use deliberate TTLs, versioned URLs, or an operational purge process. | Use deliberate TTLs, versioned URLs, or an operational purge process. |
Do not enable both modules for the same response path unless you have a specific design and understand which layer owns freshness. Double caching can make invalidation and debugging harder.
Before changing configuration
- Confirm whether the response comes from static files, an HTTP upstream, or FastCGI.
- Identify public pages whose output is identical for many visitors.
- List personalization signals:
Authorization, session or login cookies, preview flags, cart parameters, user-specific query strings, and administrator paths. - Check that the NGINX worker user can write to the planned cache and temporary directories.
- Reserve disk space for the cache, temporary files, logs, and the operating system. A cache that fills the filesystem can cause failures outside NGINX.
- Record baseline CPU, memory, disk I/O, upstream response time, error rate, and request volume.
Configure proxy caching for an HTTP application
Put proxy_cache_path in the http block, not inside a server or location block. The keys_zone value creates shared memory for cache metadata; it does not allocate the full disk cache. Keep the cache directory and temporary directory on the same filesystem when possible so NGINX can rename a completed temporary file instead of copying it.
http {
proxy_cache_path /var/cache/nginx/game levels=1:2 keys_zone=game_cache:10m max_size=1g inactive=60m use_temp_path=off;
upstream game_app {
server 127.0.0.1:3000;
keepalive 16;
}
server {
listen 80;
server_name example.test;
location / {
proxy_pass http://game_app;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache game_cache;
proxy_cache_methods GET HEAD;
proxy_cache_lock on;
proxy_cache_valid 200 10m;
proxy_cache_valid 404 1m;
proxy_cache_bypass $http_authorization $cookie_session;
proxy_no_cache $http_authorization $cookie_session $upstream_http_set_cookie;
add_header X-Cache $upstream_cache_status always;
}
}
}The names and sizes in this example are starting values, not a promise of capacity. Choose max_size, inactive, and the shared-memory zone for your disk, memory, and traffic. The cache normally handles only the methods listed in proxy_cache_methods; leave writes such as POST uncached unless you have a narrowly designed reason to do otherwise.
Understand lookup bypass versus storage prevention
proxy_cache_bypass tells NGINX not to serve an existing cached object for a request. proxy_no_cache tells NGINX not to save the response generated for that request. You usually need both. For example, a request carrying a session cookie should neither read a public object nor overwrite the public cache with a personalized response.
Cookies are application-specific. Replace $cookie_session with the actual cookie name or use a map that detects several login and preview cookies. Test anonymous, logged-in, administrator, preview, and logout flows separately.
Design the key deliberately
A key collision can serve the wrong representation, while an over-detailed key can reduce the hit rate by creating many one-use objects. Include the host and the query string when those values change the response. Exclude tracking parameters only if the application truly ignores them; removing a parameter that changes content is unsafe.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #2
proxy_cache_key "$scheme$request_method$host$request_uri";If language, device class, authorization state, or a content-negotiation header changes the body, represent that variation in the key or bypass caching for it. Do not hide a variation with proxy_ignore_headers simply to increase hits.
Configure FastCGI caching for PHP or another FastCGI app
FastCGI has its own cache module. A typical PHP-FPM setup looks like this:
http {
fastcgi_cache_path /var/cache/nginx/fastcgi levels=1:2 keys_zone=php_cache:10m max_size=512m inactive=30m use_temp_path=off;
server {
listen 80;
server_name example.test;
location ~ .php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php-fpm.sock;
fastcgi_keep_conn on;
fastcgi_cache php_cache;
fastcgi_cache_methods GET HEAD;
fastcgi_cache_lock on;
fastcgi_cache_valid 200 5m;
fastcgi_cache_valid 404 30s;
fastcgi_cache_bypass $http_authorization $cookie_session;
fastcgi_no_cache $http_authorization $cookie_session $upstream_http_set_cookie;
add_header X-FastCGI-Cache $upstream_cache_status always;
}
}
}Use the socket path, parameter include, and document root that exist on your system. The example deliberately excludes write requests and applies short lifetimes until you understand the application’s publishing behavior. A content-management system may need additional exclusions for its login, administration, preview, API, and comment endpoints.
FastCGI-specific safety checks
- Confirm that the FastCGI application sends the same output for all visitors you intend to share.
- Bypass requests with authorization headers, login cookies, preview controls, carts, or other user state.
- Prevent storage when the upstream sends
Set-Cookie, unless you have intentionally designed and reviewed that behavior. - Make sure the key includes every URI and query parameter that changes the generated page.
- Do not cache redirects, errors, or empty responses for long periods without a reason. Assign separate, short validity periods where appropriate.
Set freshness, revalidation, and stale behavior
proxy_cache_valid and fastcgi_cache_valid provide default lifetimes by status code. Upstream response headers can also control timing: X-Accel-Expires, Expires, and Cache-Control may set or override freshness according to the module’s rules. Inspect the actual headers before assuming a configured TTL is winning.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Short TTLs reduce the age of stale game-news or event data but increase origin traffic. Longer TTLs reduce origin work but require a publishing or invalidation plan. Version static assets in their filenames when you deploy them; for HTML, use a known purge or expiration procedure rather than deleting random files while workers are serving requests.
Revalidation lets NGINX ask the upstream whether an expired object is still valid instead of downloading an unchanged response. The proxy_cache_revalidate and fastcgi_cache_revalidate directives can be useful when the application supplies validators such as Last-Modified or ETag.
Stale serving is a resilience choice, not a universal optimization. Directives such as proxy_cache_use_stale and fastcgi_cache_use_stale can serve an older object during selected upstream errors, timeouts, or an update. Decide which failures are acceptable for your site: showing an older article may be preferable to an error, while an account balance or moderation action must never be treated as safely stale.
Prevent a thundering herd with cache locking
When an item expires, many visitors can miss simultaneously. Without a lock, each miss may open an origin connection and perform the same expensive query. With proxy_cache_lock on or fastcgi_cache_lock on, one request fills the missing object while other requests wait for that fill or follow the lock timeout rules. This is especially valuable on a small VPS with a limited database or PHP-FPM pool.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesLocking does not make an endpoint cacheable. It only coordinates requests that are already eligible for caching. Set a sensible lock timeout and monitor whether waiting requests become slower than an immediate origin request. For exceptionally slow or unreliable origins, combine locking with carefully selected stale behavior.
Reduce connection overhead with upstream keepalive
Keepalive reuses upstream connections so NGINX does not repeat the TCP and protocol setup for every request. For an HTTP upstream, configure an upstream keepalive pool and use HTTP/1.1 with an empty Connection header, as in the proxy example.
For FastCGI, fastcgi_keep_conn on is required for persistent connections to function. Verify that the FastCGI server and process manager support the expected connection behavior.
Keepalive is not a total connection limit. The upstream keepalive pool controls idle connections retained for reuse; workers can still open additional active connections. Set application-server limits, PHP-FPM process counts, database limits, and operating-system limits separately. Watch for file-descriptor exhaustion and queue growth instead of assuming the keepalive number caps all traffic.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Compress proxied text responses selectively
NGINX does not compress responses to proxied requests by default. Compression can reduce bandwidth for HTML, CSS, JavaScript, JSON, and XML, but it consumes CPU. Do not compress already-compressed images, video, archives, or fonts merely because they pass through NGINX.
http {
gzip on;
gzip_proxied any;
gzip_min_length 1000;
gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;
}Choose a minimum size so tiny responses do not spend CPU for negligible savings. Test compression on your VPS while watching CPU saturation and response time. If the application already compresses content, avoid an accidental second compression layer and confirm that the Content-Encoding and Vary headers are correct.
Measure whether the changes help
Add temporary cache-status information to a response header or access log during testing. Common values include MISS, HIT, BYPASS, EXPIRED, STALE, UPDATING, and REVALIDATED. Remove or restrict diagnostic headers if exposing them would reveal information you do not want public.
Compare these measurements before and after enabling caching:
- Cache-hit, miss, bypass, and error counts by URL class.
- Upstream response time and the number of requests reaching the application.
- VPS CPU and memory usage, including the database and PHP-FPM or application workers.
- Disk space, cache-directory growth, disk latency, and I/O wait.
- Client-facing latency for anonymous pages and for deliberately bypassed pages.
- Correctness across anonymous, logged-in, preview, administrator, and logout states.
A high hit rate is not automatically good. If a hit serves the wrong audience, the configuration is unsafe. If a cache consumes all disk or restart time becomes excessive, reduce its size or change its policy.
Restart and cache-management precautions
Loading a large cache index at startup can consume enough memory and I/O to slow the VPS during the first minutes after a restart. Schedule planned restarts away from traffic peaks, keep cache sizes realistic, and observe the machine during warm-up. A cache that is technically persistent can still have an operational cost after every reboot.
Validate configuration before reloading:
sudo nginx -t
sudo systemctl reload nginxA reload applies configuration without abruptly terminating existing workers, but it does not guarantee that every application-level cache is invalidated. For deployments, prefer versioned asset URLs and controlled TTLs. If you must clear a cache urgently, use a documented procedure for your distribution and NGINX version, confirm the target directory, and ensure enough free space for new temporary files.
Common failure modes and fixes
Every request is a MISS
- Check that the request is a cacheable method and that the location containing
proxy_cacheorfastcgi_cacheis actually selected. - Inspect bypass variables, cookies, authorization headers, and upstream
Set-Cookie. - Look for changing query strings, hosts, or cache keys that create a distinct object for every request.
- Confirm that the cache path is writable and that files are not immediately evicted by
max_sizeorinactive.
Logged-in users see anonymous content
Stop serving the affected cache immediately, then add bypass and no-cache rules for every authentication and session signal. Clear or expire the contaminated objects, test anonymous and authenticated sessions with separate browsers, and do not re-enable caching until the key and exclusion rules are verified.
The origin is still overloaded during a traffic spike
Check whether the spike targets uncached URLs, personalized pages, or an object expiring simultaneously for many users. Enable cache locking for eligible public endpoints, consider controlled stale serving, and examine application and database limits. Keepalive alone does not prevent request floods.
Pages are stale after publishing
Inspect response headers and the configured validity rules. Reduce the HTML TTL, add a deliberate purge or revalidation step to the publishing workflow, or use versioned URLs for assets. Do not disable all caching simply because one content class lacks an invalidation plan.
The VPS slows after a restart
Check cache size, disk activity, memory pressure, and cache-index loading. Reduce the cache footprint, move it to faster storage if available, stagger restarts, and avoid restarting during the busiest period.
A practical rollout plan
- Choose one public, read-heavy endpoint and record baseline metrics.
- Configure a dedicated cache path and shared-memory zone in
http {}; verify ownership and free disk space. - Cache only
GETandHEADresponses with a short, explicit status-based TTL. - Add bypass and no-cache rules for authorization, sessions, previews, carts, administration, and
Set-Cookie. - Expose cache status temporarily and test anonymous, authenticated, error, and deployment scenarios.
- Enable cache locking if concurrent misses burden the origin.
- Add upstream keepalive with the correct HTTP or FastCGI settings, then check active connections and file descriptors.
- Enable selective gzip only after measuring CPU and bandwidth effects.
- Expand to additional public endpoints only when correctness, disk usage, and origin load remain healthy.
This sequence keeps each change attributable. It also gives you a rollback point: remove the cache directive for the tested location, reload after nginx -t, and investigate using the metrics rather than guessing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
