starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 16:55:59 +03:00

[GH-ISSUE #5280] [bug]: Hard reload required everytime when I login on my self hosted AIO container #2018

New issue

Open

opened 2026-03-16 22:52:28 +03:00 by kerem · 9 comments

kerem commented

2026-03-16 22:52:28 +03:00

Owner

Originally created by @Shivangi0503 on GitHub (Jul 26, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5280

Originally assigned to: @mirarifhasan on GitHub.

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Platform

Web App

Browser

Chrome

Operating System

Linux

Bug Description

Issue

When I go to my selef hosted URL, I have to hard reload everytime to see all my workspaces
I thought hard reloading is only the 404 issues that we get when trying to login via google for example

but seems that I and my team have to constantly hard reload to work on things that matters.

Stack Overview

Hoppscotch AIO Docker Image: hoppscotch/hoppscotch

AWS EC2 (Amazon Linux 2)

NGINX: Installed on host to reverse-proxy requests

Docker: Used to run the all-in-one container

Google OAuth: Used for login (email whitelisting via GCP)

PostgreSQL: Hosted externally via Amazon RDS

Deployment Type

Self-hosted (on-prem deployment)

Version

No response

Originally created by @Shivangi0503 on GitHub (Jul 26, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5280 Originally assigned to: @mirarifhasan on GitHub. ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Platform Web App ### Browser Chrome ### Operating System Linux ### Bug Description ## Issue When I go to my selef hosted URL, I have to hard reload everytime to see all my workspaces I thought hard reloading is only the 404 issues that we get when trying to login via google for example but seems that I and my team have to constantly hard reload to work on things that matters. ## Stack Overview Hoppscotch AIO Docker Image: hoppscotch/hoppscotch AWS EC2 (Amazon Linux 2) NGINX: Installed on host to reverse-proxy requests Docker: Used to run the all-in-one container Google OAuth: Used for login (email whitelisting via GCP) PostgreSQL: Hosted externally via Amazon RDS ### Deployment Type Self-hosted (on-prem deployment) ### Version _No response_

kerem added the

bug

need testing

labels

2026-03-16 22:52:28 +03:00

kerem commented

2026-03-16 22:52:39 +03:00

Author

Owner

@mirarifhasan commented on GitHub (Jul 26, 2025):

Hey @Shivangi0503
Could you please make a short video showing what the UI looks like when you visit your self-hosted URL (along with the Network tab open)? Also, include what happens after you hard reload (again with the Network tab visible).

If any API throws an error, it would be helpful if you could expand the Response tab of that request and show us the exact error.

@mirarifhasan commented on GitHub (Jul 26, 2025): Hey @Shivangi0503 Could you please make a short video showing what the UI looks like when you visit your self-hosted URL (along with the Network tab open)? Also, include what happens after you hard reload (again with the Network tab visible). If any API throws an error, it would be helpful if you could expand the **Response** tab of that request and show us the exact error.

kerem commented

2026-03-16 22:52:44 +03:00

Author

Owner

@Shivangi0503 commented on GitHub (Jul 29, 2025):

@mirarifhasan
so on normally opening the self hosted url, the graphql path throws an error cause it takes the old value, you can see in the network tab.

I then did hard reload, which is taking the new configured values. and then I can see all my workspaces etc.

https://github.com/user-attachments/assets/7beb14b2-a568-40aa-9830-35d165f864e6

@Shivangi0503 commented on GitHub (Jul 29, 2025): @mirarifhasan so on normally opening the self hosted url, the graphql path throws an error cause it takes the old value, you can see in the network tab. I then did hard reload, which is taking the new configured values. and then I can see all my workspaces etc. https://github.com/user-attachments/assets/7beb14b2-a568-40aa-9830-35d165f864e6

kerem commented

2026-03-16 22:52:49 +03:00

Author

Owner

@jamesgeorge007 commented on GitHub (Aug 4, 2025):

Hi, could you try clearing your service worker cache and reloading the app to see if the issue is resolved?

@jamesgeorge007 commented on GitHub (Aug 4, 2025): Hi, could you try clearing your service worker cache and reloading the app to see if the issue is resolved?

kerem commented

2026-03-16 22:52:55 +03:00

Author

Owner

@Shivangi0503 commented on GitHub (Aug 5, 2025):

@jamesgeorge007 it did not work,

also it's not just about the graphql path, but for example, we have to hard reload the app everytime, if we (me and my team) login, select "Google" it throws 404 here there was no error thrown

https://github.com/user-attachments/assets/c328e69b-8bc3-423a-b1c8-c91c66030b7f

and after I logged in with my organization email and password, it again gives 404 and only works if I hard reload the chrome

@Shivangi0503 commented on GitHub (Aug 5, 2025): @jamesgeorge007 it did not work, also it's not just about the graphql path, but for example, we have to hard reload the app everytime, if we (me and my team) login, select "Google" it throws 404 here there was no error thrown https://github.com/user-attachments/assets/c328e69b-8bc3-423a-b1c8-c91c66030b7f and after I logged in with my organization email and password, it again gives 404 and only works if I hard reload the chrome <img width="2519" height="928" alt="Image" src="https://github.com/user-attachments/assets/d5b34401-0564-447b-8d12-0953c75a4ed9" />

kerem commented

2026-03-16 22:53:00 +03:00

Author

Owner

@mirarifhasan commented on GitHub (Aug 6, 2025):

Hi @Shivangi0503,

When you logged in via SSO and encountered the 404 error, without refreshing the browser, could you please confirm if any /graphql API calls returned an "Unauthorized" response under the Response tab in the Network tab of DevTools?

Also, did you notice any error logs in the backend container during that time?

Could you also let me know which Hoppscotch version you're currently using?

Lastly, could you share the values you've set in your .env file for the following?

ACCESS_TOKEN_VALIDITY
REFRESH_TOKEN_VALIDITY
ENABLE_SUBPATH_BASED_ACCESS

And your Nginx config, if possible.

Thanks!

@mirarifhasan commented on GitHub (Aug 6, 2025): Hi @Shivangi0503, When you logged in via SSO and encountered the 404 error, **without refreshing the browser**, could you please confirm if any `/graphql` API calls returned an **"Unauthorized"** response under the Response tab in the Network tab of DevTools? Also, did you notice any **error logs in the backend container** during that time? Could you also let me know which Hoppscotch version you're currently using? Lastly, could you share the values you've set in your `.env` file for the following? ``` ACCESS_TOKEN_VALIDITY REFRESH_TOKEN_VALIDITY ENABLE_SUBPATH_BASED_ACCESS ``` And your **Nginx config**, if possible. Thanks!

kerem commented

2026-03-16 22:53:05 +03:00

Author

Owner

@leifb commented on GitHub (Sep 2, 2025):

Hi!

We were having the same issue, but found a workaround.

Disabling the service worker sw.js in the browsers dev tools temporary fixes the issue. But this works only until the service worker is started again. It can be disabled under the Application section of the dev tools:

We were able to permanently "disable" the service worker using our apache config:

ProxyPass        /sw.js !

I don't know the nginx equivalent for that, but you just need to make sure that /sw.js does not return anything useful.

Note that after disabling the service worker via the proxy config, all users need to disable the service worker manually. Once both is done, we can reliably login.

And just to be sure, here the info requested by @mirarifhasan :

could you please confirm if any /graphql API calls returned an "Unauthorized" response under the Response tab in the Network tab of DevTools?

I did not see any 404 or other errors. All requests were 200.

did you notice any error logs in the backend container during that time?

Yes:

App/Admin Dashboard Caddy | {"level":"error","ts":1756803271.2736135,"logger":"http.log.error","msg":"dial tcp [::1]:8080: connect: connection refused","request":{"remote_ip":"::1","remote_port":"51496","client
_ip":"::1","proto":"HTTP/1.1","method":"HEAD","host":"localhost:3170","uri":"/ping","headers":{"User-Agent":["curl/8.14.1"],"Accept":["*/*"]}},"duration":0.000732326,"status":502,"err_id":"ammgfgu51","err_trace
":"reverseproxy.statusError (reverseproxy.go:1390)"}

and:

App/Admin Dashboard Caddy | {"level":"error","ts":1756803269.684629,"logger":"http.log.error","msg":"dial tcp [::1]:8080: connect: connection refused","request":{"remote_ip":"172.17.0.1","remote_port":"54662","
client_ip":"172.17.0.1","proto":"HTTP/1.1","method":"GET","host":"<our domain>","uri":"/graphql","headers":{"X-Forwarded-Proto":["https"],"Sec-Websocket-Protocol":["graphql-ws"],"Sec-Fetch-Mode":["we
bsocket"],"X-Forwarded-Host":["<our domain>"],"Sec-Websocket-Key":["<xxx>"],"Sec-Websocket-Version":["13"],"Origin":["https://<our domain>"],"Accept-Language":["en-US,en
;q=0.5"],"Sec-Websocket-Extensions":["permessage-deflate"],"Connection":["Upgrade"],"Upgrade":["websocket"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Dnt":["1"],"Sec-Fetch-Dest":["empty"],"User-Agent":["Mo
zilla/5.0 (X11; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0"],"Accept":["*/*"],"X-Forwarded-For":["<ipv6>"],"Cookie":["REDACTED"],"Pragma":["no-cache"],"X-Forwarded-Ser
ver":["<our domain>"],"Sec-Fetch-Site":["same-origin"],"Cache-Control":["no-cache"],"Sec-Gpc":["1"]}},"duration":0.000953643,"status":502,"err_id":"dy9cera8v","err_trace":"reverseproxy.statusError (r
everseproxy.go:1390)"}

Hoppscotch version

2025.8.0, and 2025.4.2

could you share the values you've set in your .env file

REFRESH_TOKEN_VALIDITY=604800000
ACCESS_TOKEN_VALIDITY=86400000
ENABLE_SUBPATH_BASED_ACCESS=false

Hope this helps!

@leifb commented on GitHub (Sep 2, 2025): Hi! We were having the same issue, but found a workaround. Disabling the service worker `sw.js` in the browsers dev tools temporary fixes the issue. But this works only until the service worker is started again. It can be disabled under the `Application` section of the dev tools: <img width="500" height="180" alt="How to disable the service worker" src="https://github.com/user-attachments/assets/9c6a8a66-532c-4879-acde-d3a376670fca" /> We were able to permanently "disable" the service worker using our apache config: ``` ProxyPass /sw.js ! ``` I don't know the nginx equivalent for that, but you just need to make sure that `/sw.js` does not return anything useful. Note that after disabling the service worker via the proxy config, all users need to disable the service worker manually. Once both is done, we can reliably login. --- And just to be sure, here the info requested by @mirarifhasan : >could you please confirm if any /graphql API calls returned an "Unauthorized" response under the Response tab in the Network tab of DevTools? I did not see any `404` or other errors. All requests were `200`. > did you notice any error logs in the backend container during that time? Yes: ``` App/Admin Dashboard Caddy | {"level":"error","ts":1756803271.2736135,"logger":"http.log.error","msg":"dial tcp [::1]:8080: connect: connection refused","request":{"remote_ip":"::1","remote_port":"51496","client _ip":"::1","proto":"HTTP/1.1","method":"HEAD","host":"localhost:3170","uri":"/ping","headers":{"User-Agent":["curl/8.14.1"],"Accept":["*/*"]}},"duration":0.000732326,"status":502,"err_id":"ammgfgu51","err_trace ":"reverseproxy.statusError (reverseproxy.go:1390)"} ``` and: ``` App/Admin Dashboard Caddy | {"level":"error","ts":1756803269.684629,"logger":"http.log.error","msg":"dial tcp [::1]:8080: connect: connection refused","request":{"remote_ip":"172.17.0.1","remote_port":"54662"," client_ip":"172.17.0.1","proto":"HTTP/1.1","method":"GET","host":"<our domain>","uri":"/graphql","headers":{"X-Forwarded-Proto":["https"],"Sec-Websocket-Protocol":["graphql-ws"],"Sec-Fetch-Mode":["we bsocket"],"X-Forwarded-Host":["<our domain>"],"Sec-Websocket-Key":["<xxx>"],"Sec-Websocket-Version":["13"],"Origin":["https://<our domain>"],"Accept-Language":["en-US,en ;q=0.5"],"Sec-Websocket-Extensions":["permessage-deflate"],"Connection":["Upgrade"],"Upgrade":["websocket"],"Accept-Encoding":["gzip, deflate, br, zstd"],"Dnt":["1"],"Sec-Fetch-Dest":["empty"],"User-Agent":["Mo zilla/5.0 (X11; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0"],"Accept":["*/*"],"X-Forwarded-For":["<ipv6>"],"Cookie":["REDACTED"],"Pragma":["no-cache"],"X-Forwarded-Ser ver":["<our domain>"],"Sec-Fetch-Site":["same-origin"],"Cache-Control":["no-cache"],"Sec-Gpc":["1"]}},"duration":0.000953643,"status":502,"err_id":"dy9cera8v","err_trace":"reverseproxy.statusError (r everseproxy.go:1390)"} ``` > Hoppscotch version 2025.8.0, and 2025.4.2 > could you share the values you've set in your .env file ``` REFRESH_TOKEN_VALIDITY=604800000 ACCESS_TOKEN_VALIDITY=86400000 ENABLE_SUBPATH_BASED_ACCESS=false ``` Hope this helps!

kerem commented

2026-03-16 22:53:10 +03:00

Author

Owner

@mirarifhasan commented on GitHub (Oct 15, 2025):

@leifb
When you encountered this issue, did you notice any high CPU or memory usage?
This error typically occurs when the backend server is unavailable.

@mirarifhasan commented on GitHub (Oct 15, 2025): @leifb When you encountered this issue, did you notice any high CPU or memory usage? This error typically occurs when the backend server is unavailable.

kerem commented

2026-03-16 22:53:15 +03:00

Author

Owner

@leifb commented on GitHub (Oct 15, 2025):

@mirarifhasan I did not notice anything like that, but I also didn't check. Do you want me to look into that? Our hack has been working fine this far, so I don't really feel the need to change anything.

@leifb commented on GitHub (Oct 15, 2025): @mirarifhasan I did not notice anything like that, but I also didn't check. Do you want me to look into that? Our hack has been working fine this far, so I don't really feel the need to change anything.

kerem commented

2026-03-16 22:53:20 +03:00

Author

Owner

@mirarifhasan commented on GitHub (Oct 16, 2025):

No worries at all @leifb — if everything’s working fine, there’s no need to check further. Thanks for confirming!

@mirarifhasan commented on GitHub (Oct 16, 2025): No worries at all @leifb — if everything’s working fine, there’s no need to check further. Thanks for confirming!