I experienced a very similar issue today where the app did not connect while all web access worked perfectly.
After many trials the reason turned out to be the DNS of Fritz!OS v7.01 on my Fritz router. Over the years I had many problems with that Fritz DNS and its name resolution. The most common problem – which hit me again today – tends to happen when Fritz sees two devices, where the name of one device is a substring of the name of the other device. In my case I had connected 2 RasPis, one named openHABianPi (the default that openHABian communicates to the DNS) and the other one openHABianPiDemo. So the name of the first was a substring of the name of the second. I should have known from the past that this invites suffering, but I thought that AVM would probably have fixed this in the mean time.
Anyway, the result of this setup is that a DNS lookup for openHABianPi returns 2 (!) IP addresses.
Here is an nslookup issued from my Mac in the same subnet as the two RasPi boxes:
$ nslookup openhabianpi
While all browsers seem to use the second IP address and work fine, the app seems to use the first one, which is the address of the “Demo” RasPi. So trying to connect to the first box through the app you either access the second box, no matter what name you use (I had this case earlier today), or you do not get an app connection to the first box if the second box is down (which I enjoyed later today).
Unfortunately AVM has closed down all easy ways to access the Fritz shell through Telnet and purge the Fritz DNS cache. The solution I finally found was to remove the second box from the list of known connections in the Fritz administration website. This removed the second IP address in the DNS resolution and all works nicely now.