Why Are PHP Cookies Not Being Created (but are with Wordpress)?

I have a ‘Ubuntu Wordpress 4.7 on 16.04’ droplet (1 click install). PHP-FPM and Varnish have been added. I’ve created an apache conf for the main domain and another for the blogs subdomain, and deactivated the default conf. I’ve edited my local hosts file to point to this server for testing.

Everything appeared to be working fine, until I hit a strange problem with cookies. I can login and use Wordpress just fine - cookies are created as expected, including the PHPSESSID cookie.

But if I create a simple session_start() test script, the PHPSESSID cookie is not created (and the session doesn’t persist).

$_SESSION["favcolor"] = "green";
echo $_SESSION["favcolor"] . "<br>";

The same script works when tested locally. I’m trying it on the server in the same directory as Wordpress. And I can see the session is being created on the server in /var/lib/php/sessions. But no browser cookies. Same if I test using setcookie(). Same if I test under the main domain.

At first I suspected a conflict with Varnish, but I’ve temporarily bypassed it while testing (using ‘return (pass)’ as the first entry in vcl_recv).

Also intriguing is that if I let Wordpress create the PHPSESSID cookie by logging in. Then my session test script DOES work. Until I delete the PHPSESSID cookie, then it won’t create it.

What am I missing? Why is this working with Wordpress but not with a regular php test script…?

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.


In that case, what I would do is disable Varnish entirely (as it shut it down) and then temporarily set up Apache to be the primary handler for requests without Varnish sitting in front.

If direct access isn’t working, my thought would be that there’s something wrong with the VCL or misconfiguration elsewhere that is preventing it from sticking.

While it may not be a major issue now, if it’s not allowing even the most basic of sessions, it may lead to issues later on down the road when you’re running production.

If that works, we know it’s an issue with Varnish. If it doesn’t, I’m a bit perplexed as baring Varnish, even a basic installation of Apache + PHP should handle sessions without any issues.


If you use your Droplet Public IP and visit your Droplet using only the IP instead of using the local host file modification for forced routing/resolution, does the cookie set?