[GH-ISSUE #955 ] Android App - Push notifications not working (Have to refresh to get messages) #668

Author

Owner

@kron0800 commented on GitHub (Nov 20, 2023):

same here, using local ip works like a charm, but if i set my cloudflared tunnel as server, no notifications received unless i refresh

@kron0800 commented on GitHub (Nov 20, 2023): same here, using local ip works like a charm, but if i set my cloudflared tunnel as server, no notifications received unless i refresh

BreizhHardware commented

Author

Owner

@Ciaran97 commented on GitHub (Nov 21, 2023):

same here, using local ip works like a charm, but if i set my cloudflared tunnel as server, no notifications received unless i refresh

@kron0800 Are you also using a proxy?

@Ciaran97 commented on GitHub (Nov 21, 2023): > same here, using local ip works like a charm, but if i set my cloudflared tunnel as server, no notifications received unless i refresh @kron0800 Are you also using a proxy?

BreizhHardware commented

Author

Owner

@emigrating commented on GitHub (Nov 21, 2023):

You guys dont happen to havea bunch of defunct ssl client ps entries do you? I ran into a similar issue (#956) which could explain why I was still getting notifications even though the web ui seemed 'dead'. As my outgoing notifications were going from the internat LAN using an apprise instance..

@emigrating commented on GitHub (Nov 21, 2023): You guys dont happen to havea bunch of defunct ssl client ps entries do you? I ran into a similar issue (#956) which could explain why I was still getting notifications even though the web ui seemed 'dead'. As my outgoing notifications were going from the internat LAN using an apprise instance..

BreizhHardware commented

Author

Owner

@Ciaran97 commented on GitHub (Nov 21, 2023):

You guys dont happen to havea bunch of defunct ssl client ps entries do you? I ran into a similar issue (#956) which could explain why I was still getting notifications even though the web ui seemed 'dead'. As my outgoing notifications were going from the internat LAN using an apprise instance..

@emigrating i dont seems to have that issue. My web UI loads fine (although i notice a spinner next to my topic and android app always says 'reconnecting' to topic but i can send notifications from both).

Edit: Also IOS notifications are working flawlessly.

@Ciaran97 commented on GitHub (Nov 21, 2023): > You guys dont happen to havea bunch of defunct ssl client ps entries do you? I ran into a similar issue (#956) which could explain why I was still getting notifications even though the web ui seemed 'dead'. As my outgoing notifications were going from the internat LAN using an apprise instance.. @emigrating i dont seems to have that issue. My web UI loads fine (although i notice a spinner next to my topic and android app always says 'reconnecting' to topic but i can send notifications from both). Edit: Also IOS notifications are working flawlessly.

BreizhHardware commented

Author

Owner

@binwiederhier commented on GitHub (Nov 21, 2023):

Please provide logs and/or screenshots. Without that, it's impossible to help.

That said, if it always says "reconnecting", that means you've never really connected to the ntfy server at all. Your Android and ntfy server logs will tell the story.

Debugging steps:

ntfy server: You can turn on debugging/tracing by setting log-level: debug or log-level: trace in the server.yml file. See https://docs.ntfy.sh/config/#logging-debugging for details.
Android app: To retrieve the logs from the Android app, go to "Settings" -> "Record logs", then eventually "Copy/upload logs".
Web app: To view the web app logs, press "F12" and find the "Console" window.

You can find details in the troubleshooting guide: https://docs.ntfy.sh/troubleshooting/

@binwiederhier commented on GitHub (Nov 21, 2023): Please provide logs and/or screenshots. Without that, it's impossible to help. That said, if it always says "reconnecting", that means you've never really connected to the ntfy server at all. Your Android and ntfy server logs will tell the story. Debugging steps: - **ntfy server:** You can turn on debugging/tracing by setting `log-level: debug` or `log-level: trace` in the server.yml file. See https://docs.ntfy.sh/config/#logging-debugging for details. - **Android app:** To retrieve the logs from the Android app, go to "Settings" -> "Record logs", then eventually "Copy/upload logs". - **Web app:** To view the web app logs, press "F12" and find the "Console" window. You can find details in the troubleshooting guide: https://docs.ntfy.sh/troubleshooting/

BreizhHardware commented

Author

Owner

@Ciaran97 commented on GitHub (Nov 21, 2023):

I have solved this. I made the assumption that because i am using a reverse proxy i did not need the port in my cloudflare tunnel.

i just added the port of my ntfy service in the local ip address of the cloudflare tunnel and i resubscribed to the topic and it worked. @kron0800 i hope the above helps you.

@Ciaran97 commented on GitHub (Nov 21, 2023): I have solved this. I made the assumption that because i am using a reverse proxy i did not need the port in my cloudflare tunnel. i just added the port of my ntfy service in the local ip address of the cloudflare tunnel and i resubscribed to the topic and it worked. @kron0800 i hope the above helps you.

BreizhHardware commented

Author

Owner

@B0F1B0 commented on GitHub (Apr 21, 2024):

I had the same problem of not getting push notifications on Android. Yes, I am behind a nginx proxy manager.

I was able to solve the problem.

on Android: Settings > Connection protocol > WebSockets
on nginx proxy manager > edit proxy host > Websockets Support [x]

@B0F1B0 commented on GitHub (Apr 21, 2024): I had the same problem of not getting push notifications on Android. Yes, I am behind a nginx proxy manager. I was able to solve the problem. on Android: Settings > Connection protocol > WebSockets on nginx proxy manager > edit proxy host > Websockets Support [x]

BreizhHardware commented

Author

Owner

@JZach commented on GitHub (Apr 30, 2024):

@B0F1B0 - had the exact same setup and the exact same problem - Websockets Support in nginx proxy manager did the trick!

@JZach commented on GitHub (Apr 30, 2024): @B0F1B0 - had the exact same setup and the exact same problem - Websockets Support in nginx proxy manager did the trick!

BreizhHardware commented

https://stackoverflow.com/a/14969925
https://nginx.org/en/docs/http/websocket.html

Author

Owner

@Ativerc commented on GitHub (Jan 7, 2025):

For people who're doing this via the nginx.conf file.


http {
...
server {
		listen 80;
		server_name local-lan-machine.internal;

		location / {
			...
		}
		
	}
	server {
		listen 80;
		server_name ntfy.local-lan-machine.internal;
		location / { 
                        # This is the part for enabling websockets
			proxy_pass http://localhost:8080;  # set to the port that ntfy is listening on
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "upgrade";
			proxy_read_timeout 86400; # I set this to 86400 because some people faced issues, so I set it this to be safer. 
		}
	}
}

Resources:

@Ativerc commented on GitHub (Jan 7, 2025): For people who're doing this via the `nginx.conf` file. ``` http { ... server { listen 80; server_name local-lan-machine.internal; location / { ... } } server { listen 80; server_name ntfy.local-lan-machine.internal; location / { # This is the part for enabling websockets proxy_pass http://localhost:8080; # set to the port that ntfy is listening on proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 86400; # I set this to 86400 because some people faced issues, so I set it this to be safer. } } } ``` Resources: https://stackoverflow.com/a/14969925 https://nginx.org/en/docs/http/websocket.html

BreizhHardware commented

Author

Owner

@wedsa5 commented on GitHub (May 27, 2025):

This should not be needed. See later comments
~~For those using Caddy reverse proxy, you can use this configuration to enable websocket:~~

ntfy.example.com {
	# Websockets, if headers match
	@ws {
		header Connection *Upgrade*
		header Upgrade websocket
	}
	reverse_proxy :<your ntfy port>
}

@wedsa5 commented on GitHub (May 27, 2025): This should not be needed. See later comments ~For those using Caddy reverse proxy, you can use this configuration to enable websocket:~ ``` ntfy.example.com { # Websockets, if headers match @ws { header Connection *Upgrade* header Upgrade websocket } reverse_proxy :<your ntfy port> }

BreizhHardware commented

Author

Owner

@binwiederhier commented on GitHub (May 27, 2025):

This is documented here: https://docs.ntfy.sh/config/#nginxapache2caddy

If the docs there are wrong, could you update them?

@binwiederhier commented on GitHub (May 27, 2025): This is documented here: https://docs.ntfy.sh/config/#nginxapache2caddy If the docs there are wrong, could you update them?

BreizhHardware commented

Author

Owner

@wunter8 commented on GitHub (May 27, 2025):

You don't need the whole @ws block for Caddy

Websockets work with just reverse_proxy :<ntfy port> on Caddy

@wunter8 commented on GitHub (May 27, 2025): You don't need the whole `@ws` block for Caddy Websockets work with just `reverse_proxy :<ntfy port>` on Caddy

BreizhHardware commented

Author

Owner

@wedsa5 commented on GitHub (May 27, 2025):

You don't need the whole @ws block for Caddy

Websockets work with just reverse_proxy :<ntfy port> on Caddy

I was getting the reconnecting issue without it. unless there was some other issue going on. but adding that block immediately fixed it for me.

@wedsa5 commented on GitHub (May 27, 2025): > You don't need the whole `@ws` block for Caddy > > Websockets work with just `reverse_proxy :<ntfy port>` on Caddy I was getting the reconnecting issue without it. unless there was some other issue going on. but adding that block immediately fixed it for me.

BreizhHardware commented

Author

Owner

@wunter8 commented on GitHub (May 27, 2025):

It must've been something else.

According to the Caddy docs, websocket proxying "just works" in v2 (the current version). You don't need to do anything to enable it. That has also been my experience.

And if I'm remembering what that block syntax means, you're matching requests that have a Connection and Upgrade header, but you never do anything for those requests. To do something special with those requests, you'd need to use this syntax: reverse_proxy @ws IP:port (with the name of that block (@ws) before the IP and port)

@wunter8 commented on GitHub (May 27, 2025): It must've been something else. According to the Caddy docs, websocket proxying "just works" in v2 (the current version). You don't need to do anything to enable it. That has also been my experience. And if I'm remembering what that block syntax means, you're matching requests that have a Connection and Upgrade header, but you never do anything for those requests. To do something special with those requests, you'd need to use this syntax: `reverse_proxy @ws IP:port` (with the name of that block (`@ws`) before the IP and port)

BreizhHardware commented