VCL rules and cache eligibility
Review request handling, relevant cookies and authentication, and the policy that determines whether a response may be shared.
SERVICES / VARNISH CACHING AND CONFIGURATION
Cache what makes sense. Protect what is private.
Make shared HTTP caching a deliberate part of your application. JetHost helps investigate Varnish behaviour and define rules for what can be stored, reused, or passed to the origin.
Understand the problem
before choosing the solution.
A low hit rate can have many causes: a session cookie, response headers, content that changes often, or rules that do not match the application. A higher hit rate is only useful when the response is correct for the person receiving it.
POSSIBLE SCOPE
What the work can include.
Freshness and invalidation
Discuss TTL decisions and how updated content becomes available. Plan controlled invalidation around the application’s publishing behaviour.
Backend behaviour
Examine origin responses and how Varnish handles requests that cannot be served from cache.
Diagnostics and private content
Investigate hits, misses, and passes, with explicit attention to authenticated requests, session cookies, Set-Cookie, and private response headers.
THE REQUEST PATHThree requests.
Three requests.
Different decisions.
A shared cache must distinguish reusable content from private information. Explore the example to see where each request goes.
A cache hit returns a stored response through Nginx to the visitor, without contacting the origin.
One possible architecture. Implementations vary; Nginx does not always need Varnish.
TYPICAL DELIVERABLESWork you can review.
Work you can review.
A handover you can use.
- A plain-English cache policy for the agreed content and request types.
- Scoped VCL changes with explanation of the relevant rules.
- Validation covering public, session, and private-response scenarios.
- Documentation of TTL, invalidation, and backend considerations.
Agreed scope. Deliberate steps.
We first identify what the application considers public and private. Then we inspect the relevant request and response behaviour, agree the policy, implement scoped rules, and test representative cases. Caching can reduce repeated origin work; it does not remove every application bottleneck or suit every response.
How an engagement worksBEFORE WE BEGIN
A few useful answers.
Can you cache signed-in users’ pages?
Personalised responses require careful isolation. The illustrated policy passes private requests without shared storage. We do not assume authenticated or session-bearing content is safe to share.
Will adding Varnish guarantee a faster site?
No fixed improvement can be promised. Benefits depend on reusable content, traffic patterns, origin behaviour, and the rest of the system.
Can you provide one configuration for every application?
No. Rules must reflect the application’s state, headers, URLs, and content lifecycle. A universal production configuration would miss those requirements.