# err_empty_response **URL:** https://discourse.roots.io/t/err-empty-response/6225 **Category:** trellis **Created:** 2016-03-16T18:28:46Z **Posts:** 6 ## Post 1 by @jankups — 2016-03-16T18:28:46Z Hi guys, It’s my first time deploying Trellis to DigitalOcean. Everything seems to be going fine, except i’m receiving the following message going to my droplet’s IP: `146.185.132.84 didn’t send any data. ERR_EMPTY_RESPONSE` Reading up it seemed perhaps it had to do with SSH agent forwarding (which i’m not familiar with). I followed [this](https://developer.github.com/guides/using-ssh-agent-forwarding/) tutorial and the response seemed fine. Locally: `You've successfully authenticated...` On the server: `You've successfully authenticated...` Where is this no data coming from? Any ideas? Thanks! Jan --- ## Post 2 by @ben — 2016-03-16T18:39:29Z Did you provision the server with an actual hostname? You’ll need to use that instead of an IP address. --- ## Post 3 by @fullyint — 2016-03-16T18:41:45Z I agree with @ben Given that I had most of this typed, I’ll still send it along… If you’re saying you’ve run `server.yml` and `deploy.yml` then you point your web browser at your IP and get an empty response, I speculate that it is because your Nginx isn’t configured to process requests to the IP name, only the domain name. Here are the [`site_hosts`](https://github.com/roots/trellis/blob/4a972f2351532338ce6803107904eb62732f558d/group_vars/production/wordpress_sites.yml#L4-L5) for which your server will process requests. By default, this doesn’t include the IP. Ultimately, you’ll want to connect using a fqdn once you have DNS set up. If that is not yet set up, I’d recommend making an entry in your local machine’s `/etc/hosts` `146.185.132.84 mydomain.com` then point your browser at `mydomain.com` instead of the IP. Maybe it would work to add the IP to the `site_hosts` list (but I vaguely remember that may have other issues with css/js relative paths not resolving). --- ## Post 4 by @jankups — 2016-03-16T23:07:01Z Thanks guys, for the quick help. I get what the problem is now: using the IP. > [@ben](#): > > Did you provision the server with an actual hostname? I did not, i’m using the droplet’s IP, which, I believe now, is causing the issue. > [@fullyint](#): > > Ultimately, you’ll want to connect using a fqdn once you have DNS set up. Indeed I would. Normally before I would put a site live, I want to have it running on an IP to test and show clients (after the local build). What would be your workflow to test a site live without having to use the actual domain? Hopefully you are able to help me adjust my strategy. --- ## Post 5 by @fullyint — 2016-03-16T23:37:45Z If you’re showing the client the site on your machine, you could use the approach I mentioned of adding a temporary entry to your `/etc/hosts`. But more likely, you want enable the client to visit the site on their own devices and you don’t expect them to mess with `/etc/hosts`. There could be many approaches, but if I had to do it right now, I’d set up DNS to point `staging.mydomain.com` to a different IP, for a new staging droplet (e.g., IP in [hosts/staging](https://github.com/roots/trellis/blob/4a972f2351532338ce6803107904eb62732f558d/hosts/staging)). I’d ask clients to visit `staging.mydomain.com` to preview the site (and to preview ongoing changes after the site is launched). This staging site shouldn’t be indexed by search engines if you’re using bedrock ([here’s why](https://github.com/roots/bedrock/blob/156a96e7138afd140ddfd682939f78ec158d8fb1/web/app/mu-plugins/disallow-indexing.php#L12-L14)), but you may still want to put the staging site behind basic auth like in “Bedrock site protect” [here](https://roots.io/trellis/docs/user-contributed-extensions/). Of course, when you’re ready to launch, add a DNS entry to point `mydomain.com` to your original IP (e.g., IP in [hosts/production](https://github.com/roots/trellis/blob/4a972f2351532338ce6803107904eb62732f558d/hosts/production)). You end up with staging and production on different droplets, different IPs, which gives you good flexibility in development. You can do anything you want to your staging server without affecting your production server. --- ## Post 6 by @jankups — 2016-03-18T10:41:17Z Thanks guys the issue has been resolved! > [@fullyint](#): > > I’d set up DNS to point [staging.mydomain.com](http://staging.mydomain.com) to a different IP This is indeed what I did. Staging is now done in a subdomain, with it’s own droplet. For future reference: The error: ERR\_EMPTY\_RESPONSE The cause: Trying to work with only the droplet’s IP The solution: Using a (sub)domain for staging ( hosts/staging ).