WordPress site front page fails to load in IE

Disclaimer: I’m a front-end guy dabbling in back-end work.

I have WordPress serving up a company Intranet site on a CentOS VM in a multiple vhost setup (LAMP). It resides at http://intranet.domain.com/ and is only accessible inside our network.

Read More

The site has been working well in Chrome and Firefox, but for some reason, the front page fails to load in IE for a few users. They can get to other parts of the site (i.e. http://intranet.domain.com/news/) by appending the path to the URL… and those pages load just fine. Up until today, it’s only affected a few other people in our company. Today, it’s finally showing itself on my machine – so I can finally debug it!

DNS Config at the moment

DNS Config shot

  1. Using Windows Server 2008 DNS.
  2. Research led me to create a new Forward Lookup Zone called intranet.domain.com.
  3. I was directed to create an unnamed A record that pointed to the the IP of the CentOS box.

Apache vhost config

Intranet vhost config shot

Troubleshooting

IE 11, Win 7 x64.

  1. Open IE w/ http://intranet.domain.com set as homepage. Fails to resolve.
  2. Refresh. Still nothing.
  3. Append /news/ to URL and the page loads without issue.
  4. Click home link. Fails to resolve.
  5. Pings to intranet.domain.com return from proper internal IP: 192.168.50.89.
  6. Test in Chrome & Canary… intranet.domain.com Loads w/o issue.
  7. Test in Firefox & Aurora… intranet.domain.com Loads w/o issue.
  8. Test http://capsule.domain.com in IE (setup the same way intranet is in DNS)… loads w/o issue.
  9. Notice that it redirects to http://capsule/wp-admin/
  10. Test http://intranet/ in IE. Loads!
  11. Close IE, open IE (intranet.domain.com still set as Home)… Fails.
  12. Config IE to open http://intranet/ and http://intranet.domain.com/ in two tabs at startup.
  13. Close IE, open IE … FQDN tab fails. http://intranet/ LOADS.

What gives?

Anyone encountered anything like this?


Update (3/5)

Looks like opening the site in IE’s InPrivate mode at the fqdn works. Then, closing IE and reopening it normal mode and all is well.

Stumped as to why this is… but that workaround has gotten the affected users into the site successfully.

Related posts