Este site irá ter funcionalidade limitada enquanto fazemos manutenção para melhorar a sua experiência. Se um artigo não resolve o seu problema e quiser colocar uma questão, temos a nossa comunidade de apoio à espera de o ajudar em @FirefoxSupport no Twitter, /r/firefox no Reddit.

Pesquisar no apoio

Evite burlas no apoio. Nunca iremos solicitar que telefone ou envie uma mensagem de texto para um número de telefone ou que partilhe informações pessoais. Por favor, reporte atividades suspeitas utilizando a opção "Reportar abuso".

Saber mais

Firefox for Linux [Flatpak] takes minutes to start when behind VPN.

  • 5 respostas
  • 1 tem este problema
  • 1 visualização
  • Última resposta por jonzn4SUSE

more options

The issue concerns the Flatpak version of Firefox on Linux. This issue only happens when I'm connected to my VPN router. For info, I'm using Fedora 35 Silverblue. This issue happens on Fedora 35 or Fedora 35 Silverblue. I been using Fedora since version 33 and such problem existed back then.

When connected to my VPN provider via my router, trying to start a Firefox Flatpak instance takes minutes upon minutes to load. I'm guessing it has to do with DNS query's Firefox does on start but I'm not sure. All I know is that when I connect directly to the internet without being hehind my VPN, Firefox loads in a split second. When I'm using the RPM version of Firefox supplied by Fedora, I do not have such issues even when connected to my VPN. This issue only affects Firefox Flatpak when behind a VPN. I tried opening the AppImage version of Firefox while connected to my VPN, and once again, it loaded within a few seconds. I been having this issue for many years and only figured out recently that my VPN connection was causing a problem.

I would like to point out that the Flatpak verion of Microsoft Edge and Chromium do start without any issues even while I'm connected to my VPN provider...

The issue concerns the Flatpak version of Firefox on Linux. This issue only happens when I'm connected to my VPN router. For info, I'm using Fedora 35 Silverblue. This issue happens on Fedora 35 or Fedora 35 Silverblue. I been using Fedora since version 33 and such problem existed back then. When connected to my VPN provider via my router, trying to start a Firefox Flatpak instance takes minutes upon minutes to load. I'm guessing it has to do with DNS query's Firefox does on start but I'm not sure. All I know is that when I connect directly to the internet without being hehind my VPN, Firefox loads in a split second. When I'm using the RPM version of Firefox supplied by Fedora, I do not have such issues even when connected to my VPN. This issue only affects Firefox Flatpak when behind a VPN. I tried opening the AppImage version of Firefox while connected to my VPN, and once again, it loaded within a few seconds. I been having this issue for many years and only figured out recently that my VPN connection was causing a problem. I would like to point out that the Flatpak verion of Microsoft Edge and Chromium do start without any issues even while I'm connected to my VPN provider...

Solução escolhida

I found the problem. One of my VPN router's was causing the issue!!... The problem is now resolved.

Thank You.

Ler esta resposta no contexto 👍 1

Todas as respostas (5)

more options

So it's not a Mozilla browser issue right?

Modificado por jonzn4SUSE a

more options

Hello jonzn4SUSE,

I have no idea what causes the problem, all I know is that I been having this issue for many years and I'm getting tired of it. I would like to use Firefox as a Flatpak on my Linux distro, Fedora in this case and doing so while connected to my VPN...

I'm not a technical expert, I found a bug and I'm only looking for someone who might be able to help and solve the issue once and for all.

Regards.

MR

more options

Hi MR!

As this seems like a clear cut enough issue, I'd recommend filing this as a bug in Bugzilla directly.

Regards, Balázs

more options

Solução escolhida

I found the problem. One of my VPN router's was causing the issue!!... The problem is now resolved.

Thank You.