The first one? No 
The second one indeed does!
I would have expected to see the ip here. Instead, it seems to use a domain name. So either the nginx server was not restarted after changing the dns entry and host ip (nginx is known to cache resolved dns entries until is stopped), or the host uses a different dns server, or in case of the default bridge network has a local entry in /etc/hosts.
Since nginx is running in a container, you not simply use proxy_pass http://localhost:12000 (which would have solved it, if nginx would be service on the host). Though, as the containers are attached to the default bridge, you can not use service discovery.
If you’d create a container network and attach the containers to the network, you could use the container name instead of myserver.org, but it requires an additional step to mitigate the indefinitely caching of resolved dns entries.
# create the user defined network
docker network create web
docker run \
--name my-nginx \
--network web \
--restart=always \
-v /srv/nginx/conf:/etc/nginx/conf.d:Z \
-v /srv/nginx/www:/var/www \
-v /srv/nginx/log:/var/log/nginx \
-v /srv/nginx/sys:/sys \
-v /cert:/cert \
-p 80:80 \
-p 443:443 \
-d \
nginx
docker run \
--name myapp \
--network web \
--restart=always \
-v /srv/myapp/attachment:/app/public/attachment \
-v /srv/myapp/system:/app/public/system \
-v /srv/myapp/log:/app/log \
-p 12000:8080 \
-d
myappdb unicorn_rails -E production -c /app/config/unicron.rb
This allows to use proxy_pass http://myapp:8080; instead. It uses the container name, and application port from inside the container. Furthermore, it allows removing the published port on the container, as it’s already accessible through nginx.
You can mitigate the dns caching issue by applying the settings discussed in the posed to your nginx.conf: NGINX swarm redeploy timeouts - #5 by meyay
That should do the trick.
You should consider migrating your docker run commands into docker compose files. As a positive side effect you can version the compose files in git and keep track of changes.
Update: I forget to address the restart problem. A container restart is nothing else than docker stop && docker start, thus it shouldn’t behave any differently.