There has to be a server responding to your request, yeah? The exercise is meant to start it when you open the exercise.
Let’s see what’s running in a system backing that exercise:
$ ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
ccuser 1 0.0 0.0 4512 796 ? Ss 00:07 0:00 /bin/sh -c python -c "import pandas" && node -e "require('mocha')" && /usr/local/bin/ein -service-port 4000 -http-port 4001
ccuser 30 0.0 0.0 147480 13720 ? Sl 00:07 0:00 /usr/local/bin/ein -service-port 4000 -http-port 4001
ccuser 37 12.1 0.0 161508 61372 ? Sl 02:13 0:01 /usr/bin/ruby2.3 bin/rails server -p 4001 -b 0.0.0.0
ccuser 42 0.0 0.0 18236 3108 pts/0 Ss 02:13 0:00 bash
ccuser 47 0.0 0.0 34428 2772 pts/0 R+ 02:13 0:00 ps aux
The process with PID 37 is the rails server. This has probably been killed/crashed in your instance.
If you look at the process with PID 1, you can see it was started 2 hours before 37, 42, 47 - those containers are somewhat persistent. It’s not unthinkable that you just get reconnected to the same one when you reload the page.
Most likely, this issue will have magically resolved itself next time you try, because it’s been a few hours, your instance has probably stopped by now, and trying again gets you a new one.
If not, you could stop it yourself.
pkill -u ccuser (kill all processes, effectively logging you out), reloading the page will then get you a new instance which would have a rails server running in it.
Alternatively, you could start the server yourself. You can see the command in ps’s output above:
ruby bin/rails server -p 4001 -b 0.0.0.0
(port 4001 is the one exposed on that system, it gets remapped to 8000 somewhere else)