Docker routing/reverse proxy issue, can't curl other container - http

Question

I have a single docker host running 2 web apps inside of individual containers. I have an nginx container setup in front of both of them acting as a reverse proxy. There are two dns entries for different subdomains pointing to this single host so I can reach app 1 with app1.domain.com and app2 with app2.domain.com. This setup is working fine, and each app is accessible to the broader universe.
However, app2 also needs to be able to make an http call to webservices provided by app1. For some reason, the http calls to http://app1.domain.com can't be resolved from within the app2 container. curl http://app1.domain.com returns Failed to connect to app1.domain.com port 80: No route to host. Oddly, I can ping app1.domain.com from within app2's container and it successfully resolves to the hosts url. I have tried disabling iptables with service iptables stop on the docker host and that causes the both the curl and ping commands to simply hang for a while before finally returning an error about unknown host for ping and could not resolve host for curl.
Finally, I can curl from app2's container to app1 using the docker ip address and port, though that is not an ideal solution given that it would require changing how this app is deployed and configured so that this ip address and port can be discovered.
UPDATE: Output of iptables -n -L -v -x
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- eth1 * 10.191.192.0/18 0.0.0.0/0
124 6662 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
3 120 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
141668 14710477 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432
252325 512668022 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
31 2635 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
5496 331240 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
623 37143 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
437791 334335762 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0
438060 347940196 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
680992 61107377 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0
356 24168 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 604 packets, 125207 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * eth1 0.0.0.0/0 10.191.192.0/18
124 6662 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:81
0 0 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:443
2191 156283 ACCEPT tcp -- !docker0 docker0 0.0.0.0/0 172.17.0.2 tcp dpt:80
0 0 ACCEPT tcp -- docker0 docker0 172.17.0.60 172.17.0.7 tcp dpt:3000
0 0 ACCEPT tcp -- docker0 docker0 172.17.0.7 172.17.0.60 tcp spt:3000
app1 docker ip: 172.17.0.7
app2 docker ip: 172.17.0.60

Answer 1

You can link your docker containers and then use the link to directly talk to app1 from within app2. In this way you can avoid dns resolution, and hence would be faster.
Assuming you are running the containers in the following way:
docker run --name app1 app1-image
docker run --name app2 --link app1 app2-image
Now from within app2 container you can access app1 with the hostname 'app1'