Mattermost Peer-to-Peer Forum

Issue connecting via mobile device using browser



Page does not load when trying to connect using mobile browser (Safari)

Steps to reproduce

Running the server and trying to access the instance from mobile browser.
The server version is 4.2, but the behavior was the same on 3.7.1.

Expected behavior

The expected behavior is to see the login page so users can login and use the app.

Observed behavior

Instead of the expected behavior we see an animation of 3 dots and that is it. You can see that in this image:

I have enabled DEBG messages and when I load the page with a desktop version of chrome in mobile mode the log shows:

[2017/09/20 13:09:38 PDT] [DEBG] /
[2017/09/20 13:09:39 PDT] [DEBG] GET - /api/v4/config/client
[2017/09/20 13:09:39 PDT] [DEBG] GET - /api/v4/license/client

When I access the site from my mobile device using Safari Browser in the logs I only see:

[2017/09/20 13:12:57 PDT] [DEBG] /

My assumption is that it is trying to serve the page which recommends using the mobile app and unable to do it for some reason, Is there a way to bypass that behavior and just force loading the login page? Any other ideas


Thanks @attzonko, let’s see

1 - Do you know if you logged into the server on mobile browser before?

If yes (or you’re not sure), on your desktop browser, can you

  • go to Account Settings > Security > View and Logout of Active Sessions
  • find the session related to your mobile browser, and hit “Logout”.

That’ll revoke your mobile browser session, so you can start fresh.

2 - If 1 doesn’t help, can you go to System Console > Customization > Mattermost App Links, and remove

  • Android App Download link
  • iOS App Download link

That’ll bypass the “Download Mattermost App” page, to see if that’s causing an issue.

If neither of the above helps,

3 - Does this reproduce on multiple devices?
4 - If only on certain ones, what device and OS are they?
5 - Are you able to load on your mobile browser (our community instance)?


Thanks for the response.

  1. This is the first time we are trying to enable mobile devices, so there were no active sessions. Regardless I logged out all my active sessions and still saw the same behavior.
  2. I cleared those two text boxes and restarted the server. Still saw the same behavior,
  3. I am the first one trying to enable this feature, so don’t have much data from other users yet.
  4. I am on iphone 7 plus ios 10.3.3
  5. Yes no problem loading the pre-release instance.


I had someone with Android (7.1.1) try it and got the same result


Hey @attzonko,

I have a couple of quick questions for you: How are you hosting Mattermost? (local, docker, gitlab, etc) and if you are using NGINX as a proxy for Mattermost, Does your config match ?




Hi, thanks for the response.

We are using a local instance.

The nginx matches the config in the document you linked with one difference, we use https instead of http so the traffic is encrypted here is what we have:

upstream backend {

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=mattermost_cache:10m max_size=3g inactive=120m use_temp_path=off;

server {
   listen 80;
   return 302 https://$server_name$request_uri;

server {
   listen 443 ssl http2;
   access_log /var/log/nginx/example.access.log;
   error_log /var/log/nginx/example.error.log;

   ssl on;
   ssl_certificate /etc/apache2/ssl/mm_ssl.crt;
   ssl_certificate_key /etc/apache2/ssl/ssl.key;
   ssl_session_timeout 5m;
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers on;
   ssl_session_cache shared:SSL:10m;

   location ~ /api/v[0-9]+/(users/)?websocket$ {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 50M;
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       proxy_read_timeout 600s;
       proxy_pass https://backend;

   location / {
       client_max_body_size 50M;
       proxy_set_header Connection "";
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       proxy_read_timeout 600s;
       proxy_cache mattermost_cache;
       proxy_cache_revalidate on;
       proxy_cache_min_uses 2;
       proxy_cache_use_stale timeout;
       proxy_cache_lock on;
       proxy_pass https://backend;



Sorry about the late reply, I’ve been rather busy at work and wanted to give this issue the proper attention so that we can get it resolved. I’d like to ask a few things to see if we can narrow down the scope of the issue further:

  1. Does this issue occur if you install the Mattermost app from the app store?
  2. is your iPhone on a wireless (WiFi) network, if so have you taken a laptop and connected to the exact same wifi network (after flushing your laptop’s dns cache) to test that it isn’t a DNS issue or a routing (VLAN) issue

I’d also be game for troubleshooting this with you on the pre-release mattermost server under Peer-to-Peer help if you wanted to get a quick fix for it.


  1. We cannot use the actual app because the instance is sitting behind a corporate firewall. The only way we can get to the instance is using our corporate browser app designed to get through the firewall. That is why I am only testing with a browser not the actual mobile app.
  2. The fact that I see an access log on mattermost side tells me it is probably not a network connectivity issue. Does that make sense?




I’m going to need to know more because i’m almost certain this issue is due to your network setup. this is pure conjecture but is your firewall doing SSL Inspection? if so, do the phones have the SSL Inspection cert installed on them?



Well, if I change the nginx back-end to point to another internal SSL enabled page that page loads fine. I will keep digging on my end and will let you know what else I find.