I'm using Ubuntu (Lucid Lynx) to learn Ruby On Rails. I'm running Ubuntu in VirtualBox (the host is Windows 7 Ultimate), using bridged networking.

When I run my Rails app and point the browser at it using localhost:3000, the app responds immediately and my page is rendered in a second or two.

However, if I use (where is my IP address reported using ifconfig), the response from my rails app is incredibly slow - maybe 30 seconds or more for the server to respond and render the page.

This happens in both Firefox and Chrome. Also, when I hit the Rails app from the host (to test it in IE), I get the same slooooooow response.

Any ideas what might be going on? I've tried it with two different routers, and on two different networks (work and home) with the same result.

Cheers all.

  • 1
    Are other connections to the virtual Ubuntu box also very slow? How about connecting the other way, from the Ubuntu VM to the Windows host?
    – CarlF
    Sep 1, 2010 at 12:39
  • I can ping the Ubuntu guest from the Windows host, and the ping replies are immediate. Also, connections from the Ubuntu guest to the Windows host (eg to an IIS website on Windows) are fast. The only slowness is when I hit the Ubuntu Rails server using the IP address. Using localhost is fine. Sep 2, 2010 at 7:34
  • I'm having the same problem, but no matter if I use 'localhost' or the numeric IP, the responses is terrible slow. It takes a couple of seconds to load each resource (an image, a js, whatever). I've tried mongrel, thin, unicorn... I guess the only solution is to use passenger under apache right?
    – empz
    Apr 14, 2011 at 20:14
  • could be related to reverse dns lookups.
    – wnrph
    Aug 29, 2011 at 14:55
  • This article might provide an answer : stackoverflow.com/questions/1156759/…
    – Etienne
    Feb 27, 2014 at 13:53

6 Answers 6


Try running

sudo service avahi-daemon stop

Also try setting WEBrick /usr/lib/ruby//webrick/config.rb

:DoNotReverseLookup => true

Also see: "Stackoverflow WEBrick slow from remote desktop"

  • +1 stopping Avahi had an immediate impact. Could you provide an explanation as to why?
    – Amro
    Mar 17, 2012 at 0:16
  • @Amro, not sure. http://mercenary-code.blogspot.co.uk suggested it and mentions deleting the symlink from /etc/rc3.d so it doesn't restart. This Lighthouse ticket mentions avahi trying to resolve the reversemapping of causing a timeout. http://qzdrproject.wordpress.com did the digging in strace/wireshark to find the solution.
    – James EJ
    Apr 9, 2012 at 18:48
  • This worked for me, it does seem to be caused by a reverse lookup which eventually times out.
    – Ed Bishop
    Jun 19, 2013 at 22:17

It is WEBrick issue, no problems when you use other web servers.

I tried Mongrel and Thin with Ruby on Rails 3.0.x, both working great.

I suggest using Mongrel - simply add it to your Gemfile:

gem "mongrel"

or you can set it only for development and test, not to break production:

group :test, :development do
  gem "mongrel"

Now start server same way as you did before and Mongrel starts instead of WEBrick.

If you prefer Thin, you need to start server with thin start or WEBrick will be started.


I've had this same problem occur under both VirtualBox and VMware. Not sure what the problem is... it acts like the Rails server is looking something up that has to be timed out? Rails server reports fast render times in log, but takes forever to respond to each request. Happens in both Rails 2.3.8 and Rails 3.0.3 for me on one particular Ubuntu instance (tried under both VirtualBox and VMware). I've had another Ubuntu VM on another box that didn't have the problem...

After frustratingly chasing this for some time, my solution is to use Phusion Passenger in development mode and Apache.


Warning: this is a non-answer (other than the suggestion just to use Passenger), but I'm documenting my own experience as well as some experiments that I did that hopefully help us come closer to a conclusion.

I have the exact same issue. It came up suddenly. I also have a similar observation to you on the ping front. My Ubuntu guest also runs a regular LAMP stack, and there are absolutely no service issues there. For what it's worth, it seems like unix_stream_data_wait is (mostly?) to blame for the hangup. I can't really parse what this means beyond the trivial or how to investigate further.

This seems to be independent of port number (moving rails to a lower port as in rails s -p 30 doesn't change the issue, and other services set to listen to port 3000 don't encounter the same service issues).

It also seems to be independent of the application code. I tried it with a bare rails app, and the delay reappeared.

The delay also seems to vary in duration, raising a potential problem with the hypothesis that Rails is timing out predicably.

Requests sent in the same "batch" seem to be fulfilled at the same time. This suggests that there's something in the interface between the Rails process and the network handler, where the interface is just damned slow but clears his plate when the transaction eventually does go through.

Overall, weird weird weird.

I just went with passenger instead.


This one is really strange. I've found out, that if I start rails server from putty responses are much faster, than if I start it from VirtualBox window...


If you are using WEBrick, you can try using Thin instead. Add thin to your Gemfile:

gem 'thin'

and install it by running:


Start the server by running:

thin start

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .