Use of “localhost” when installing Magento 2 (Quick Note)

I never quite understood why using localhost as the host name did not work with Magento, for example when developing on your laptop Using works, but localhost does not. For a while I thought it was some weird Magento restriction I did not understand, but the penny finally dropped when someone explained it (again) to me recently. has a good description. It is not Magento, it’s that web browsers behave differently when used with a domain name with less than 2 dots in it, such as localhost. The cookies are not saved.

So the easiest solution is either to use or add a domain name to your local hosts file (/etc/hosts under Linux or C:\WINDOWS\System32\drivers\etc\hosts on Windows) with something like the following in it.

Using as the domain name will then result in cookies behaving correctly. Mystery solved!

(I will leave deeper explanations to brighter minds than mine…)


  1. Hm… For me it works with one dot: magento2.lh

  2. “localhost” is special. When connection to MySQL it instructs the client to use the UNIX socket instead of TCP/IP.

    On Unix, MySQL programs treat the host name localhost specially, in a way that is likely different from what you expect compared to other network-based programs. For connections to localhost, MySQL programs attempt to connect to the local server by using a Unix socket file. This occurs even if a –port or -P option is given to specify a port number. To ensure that the client makes a TCP/IP connection to the local server, use –host or -h to specify a host name value of, or the IP address or name of the local server. You can also specify the connection protocol explicitly, even for localhost, by using the –protocol=TCP option.

    1. Thanks for the comment. I should have been clearer that I was only referring to the use of “localhost” for the domain name in URLs, not for MySQL or other services. It is in a URL that causes a problem due to cookie management in the web browser.

  3. Small correction/clarification — there’s no restriction in PHP on using cookies or (by extension) PHP sessions with the localhost domain. This small script (loaded in a browser) will work

    $value = array_key_exists('test', $_COOKIE) ? $_COOKIE['test'] : 0;
    setcookie('test', $value);
    $value = array_key_exists('test2', $_SESSION) ? $_SESSION['test2'] : 0;
    $value = $value ? $value : 0;
    $_SESSION['test2'] = $value;

    view raw


    hosted with ❤ by GitHub

    The code at the above gist will remember the value set in the cookie and session, and successfully increment it on each page load.

    The problem with using localhost and Magento stems from the core session handling code in `app/code/core/Mage/Core/Model/Session/Abstract/Varien.php`, and cookie handling code in `app/code/core/Mage/Core/Model/Cookie.php`. These files set an **explicit** domain for the cookie. That, combined with the undefined behavior for cookie domains that aren’t fully qualified domain names ( is what leads to a Magento site accessed via `localhost` not setting cookies (and again, by extension, session values).

    If you look at the response headers for the script that works (, you’ll see something like this.

    $ curl -I ‘http://localhost/test.php’

    Set-Cookie: test=1
    Set-Cookie: PHPSESSID=b7dhq11mfp98q85p1ic284cii7; path=/

    That is, the cookies have no explicit domain set. Browsers seem able to cope with this.

    However, try this with a Magento site, and you’ll see

    $ curl -I ‘http://localhost:8080/’
    Set-Cookie: frontend=inu7rsnitggt315mrrv5fl7lf5; expires=Mon, 27-Apr-2015 06:19:57 GMT; path=/; domain=localhost; HttpOnly

    That is, a cookie an explicit domain set.

    I mention this mainly because there’s a lot of “internet folk development” circulating that says you can “fix” numerous Magento session bugs by commenting out the session setting lines. Here’s one example of that

    This, of course, leads to numerous other bits of unpredictable site behavior.

    I can see how, from a certain point of view, it’s easy to say this is the browser’s fault, or PHP’s fault. That said, a case could be made that Magento 2 should make an effort in its cookie and session handling code to work through these ambiguities and provide an application that will work when accessed by a non fully qualified domain name (localhost, servername, etc.). The status quo leads users to comment out core parts of the Magento system and create other instabilities. Additionally, Magento 2 seems to be moving towards more vagrant oriented development, where there’s a culture of using localhost or non-fully-qualified server names to access your development VM.

    1. Thanks Alan, I will see what we can do for Magento 2.

  4. We use and shove in etc/hosts. Then we forget about the issue, its just part of process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: