# fly.toml health checks and Rails config.hosts

**URL:** <https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580>\
**Category:** General\
**Tags:** login-only\
**Created:** [June 27, 2024, 1:05am UTC](https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580 "2024-06-27T01:05:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Youdaman](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/youdaman/32/35625_2.png) [@Youdaman](https://community.fly.io/u/Youdaman)\
**Post date:** [June 27, 2024, 1:05am UTC](https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580/1 "2024-06-27T01:05:42Z")

</div>

Note: I’ve changed my URL to `foo.fly.dev` and IP/port to `x.x.x.x:x` below.

Problem (via `fly logs`):

```auto
2024-06-27T00:54:43Z health[2865945fe95498] syd [error]Health check on port 3000 
has failed. Your app is not responding properly.
2024-06-27T00:54:53Z app[2865945fe95498] syd [info]E, [2024-06-27T00:54:53.520223 #323] ERROR -- : [ActionDispatch::HostAuthorization::DefaultResponseApp] Blocked hosts: x.x.x.x:x

```

Solution (in `config/application.rb`):

```auto
    config.hosts << "foo.fly.dev"
    config.hosts << "x.x.x.x:x"

```

When I first tried to `fly deploy` it hung on the health check because the Rails config did not allow the IP/port that was used when trying to hit the health endpoint, defined in `config/routes.rb` as:

```auto
  get "up" => "rails/health#show", :as => :rails_health_check

```

So firstly I commented-out the entire checks section of the fly.toml config:

```auto
[checks]
[checks.status]
port = 3000
type = 'http'
interval = '10s'
timeout = '2s'
grace_period = '5s'
method = 'GET'
path = '/up'
protocol = 'http'
tls_skip_verify = false

[checks.status.headers]
X-Forwarded-Proto = 'https'

```

By prepending each line with a `#`

Then I was able to deploy without issue. After uncommenting that section though I still found I had a problem and when I checked `fly logs` I could see the problem above.

My question is will my IP address for my app change? If so then I’ll have to keep updating my config to allow each new IP/port. I could also use a regex rule if there’s a set range that [Fly.io](http://Fly.io) uses? Is there another way around this or a better solution?

---

<div class="post-metadata">

**Author:** ![rubys](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/rubys/32/16907_2.png) [@rubys](https://community.fly.io/u/rubys)\
**Post date:** [June 27, 2024, 1:31am UTC](https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580/2 "2024-06-27T01:31:26Z")

</div>

First, just a guess. Are you trying to run your Rails app in development mode? That’s not recommended.

Your IPv6 address may change over time if your app is moved to another host. That is something that is done from time to time. But you really shouldn’t have an issue with blocked hosts.

If you are willing to experiment, create a second application. You can delete it when done:

```auto
rails new demo --minimal
cd demo
echo 'Rails.application.routes.draw { root "rails/welcome#index" }' >> config/routes.rb
fly launch

```

Press enter when you see:

```auto
? Do you want to tweak these settings before proceeding? (y/N)

```

Unless [you are running Ruby 3.3.3](https://community.fly.io/t/ruby-3-3-3-net-pop-bug-mitigation/20504), things should just work. If you are running 3.3.3, add the following:

```auto
bin/rails generate dockerfile --force
fly deploy

```

If you check your logs, you may see a line like the following before puma starts, but it is benign:

```auto
2024-06-27T01:26:22Z health[90801679a10038] iad [warn]Health check on port 3000 is in a 'warning' state. Your app may not be responding properly.

```

Once puma starts, you should see:

```auto
2024-06-27T01:26:29Z health[90801679a10038] iad [info]Health check on port 3000 is now passing.

```

If you reproduce these steps, the question to be resolved is what is the difference in the configuration of these two applications?

---

<div class="post-metadata">

**Author:** ![Youdaman](https://sea1.discourse-cdn.com/fly1/user_avatar/community.fly.io/youdaman/32/35625_2.png) [@Youdaman](https://community.fly.io/u/Youdaman)\
**Post date:** [June 27, 2024, 1:54am UTC](https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580/3 "2024-06-27T01:54:12Z")

</div>

Thanks @rubys I just found the solution.

Just as I was spinning up a minimal Rails app as per your suggestion, I googled to find the page about the `config.hosts` and why it’s a good idea:

> **[Securing Rails Applications — Ruby on Rails Guides](https://edgeguides.rubyonrails.org/security.html#dns-rebinding-and-host-header-attacks)**
>
> Securing Rails ApplicationsThis manual describes common security problems in web applications and how to avoid them with Rails.After reading this guide, you will know: All countermeasures that are highlighted. The concept of sessions in Rails, what...

I noticed it had a `config.host_authorization` part and so checked my code for this and found this in `config/environments/production.rb`:

```auto
  # Skip DNS rebinding protection for the default health check endpoint.
  # config.host_authorization = { exclude: ->(request) { request.path == "/up" } }

```

After uncommenting the second line above and also removing the now unnecessary Fly host IP/port from my `config.hosts` in `config/application.rb`, I did another `fly deploy` and things worked fine!

Hopefully this will help others out there trying to deploy Rails apps! It’s probably a noob mistake on my part being relatively new to the framework, but it’s also nice to know these security measures are baked into the configuration.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/fly1/original/3X/6/e/6e8955d00cb218e186ebbe3a6ab06fefdce15290.svg) [@system](https://community.fly.io/u/system)\
**Post date:** [July 4, 2024, 1:54am UTC](https://community.fly.io/t/fly-toml-health-checks-and-rails-config-hosts/20580/4 "2024-07-04T01:54:42Z")

</div>

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
