Unable to connect when running 7.2.0 (also random "crash")

[aureq]

Using a supported version?

• I have searched searched open and closed issues for duplicates.
• I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Up until 7.2.0, Signal used to work with a web proxy (squid-cache). I just got notified to restart Signal to run on the latest version and since the connection status shows as "Disconnected".

If I click the yellow notification to reconnect, the nothing happens. Looking at the proxy's log it doesn't seem like Signal is initiating any connection with the signal servers. I don't see any attempts to connect directly either.

After deleting all files (application and application data), during the initial startup, Signal couldn't display the QR Code either.

I did try to submit the debug logs (debuglogs.org), but they seem to ignore the proxy settings (the local socket is in SYN_SENT state). Though, I saved both log files and made an archive attached to this issue and emailed them to the support email address with a reference to this issue.

On the random "crash", I noticed that sometimes the Signal window would just disappear a few seconds after opening the app.

signal-debugs.zip

Steps to reproduce

Scenario 1: Upgrade (see debuglog-post-7.2.0-upgrade.txt)

1. Have a proxy
2. Set the env variables HTTP_PROXY, HTTPS_PROXY pointing to your proxy
3. Signal start ✅
4. The connection stays on Disconnected ❌

Scenario 2: New install (see debuglog-new-install.txt)

1. Have a proxy
2. Set the env variables HTTP_PROXY, HTTPS_PROXY pointing to your proxy
3. Signal start ✅
4. The QR Code is not displayed ❌
5. Clicking Retry doesn't change the outcome ❌

Scenario 3

1. Have a proxy
2. Set the env variables HTTP_PROXY, HTTPS_PROXY pointing to your proxy
3. Signal start ✅
4. The QR Code is not displayed ❌
5. Click View -> Debug logs -> Submit
6. There's a loading image spinning and then comes back to the debug log window ❌ (see 2nd screenshot)

Expected result

Signal connects to its network via the designated proxy.

Actual result

Signal stays disconnected.

Screenshots

Signal version

7.2.0

Operating system

Windows 10

Version of Signal on your phone

7.0.2

Link to debug log

No response

[Ockenheimer]

Same issue here at work

Clients not updated to 7.2.0 connect just fine.
Updated Clients won't connect

[ichEben]

Same issue here; Since Updating from 7.1.1 to 7.2 the proxy wont connect anymore.
Previous Version works fine

[grufocom]

Error
at connect ([REDACTED]\resources\app.asar\preload.bundle.js:86:527148)
at vk.connectResource ([REDACTED]\resources\app.asar\preload.bundle.js:86:534838)
at vk.authenticate ([REDACTED]\resources\app.asar\preload.bundle.js:86:529317)
at vk.getAuthenticatedResource ([REDACTED]\resources\app.asar\preload.bundle.js:86:531017)
at vk.fetch ([REDACTED]\resources\app.asar\preload.bundle.js:86:531691)
at _promiseAjax ([REDACTED]\resources\app.asar\preload.bundle.js:86:545833)
at _retryAjax ([REDACTED]\resources\app.asar\preload.bundle.js:88:702)
at [REDACTED]\resources\app.asar\preload.bundle.js:88:798
Caused by: Error: createProxyAgent: all=true lookup is not supported

workaround: if you change the proxy settings from a fwdn to the ip-address the signal client can connect again!

there seems to be a bug in the name resolution.

a quick fix would be great! :-)
thx

[ichEben]

Error at connect ([REDACTED]\resources\app.asar\preload.bundle.js:86:527148) at vk.connectResource ([REDACTED]\resources\app.asar\preload.bundle.js:86:534838) at vk.authenticate ([REDACTED]\resources\app.asar\preload.bundle.js:86:529317) at vk.getAuthenticatedResource ([REDACTED]\resources\app.asar\preload.bundle.js:86:531017) at vk.fetch ([REDACTED]\resources\app.asar\preload.bundle.js:86:531691) at _promiseAjax ([REDACTED]\resources\app.asar\preload.bundle.js:86:545833) at _retryAjax ([REDACTED]\resources\app.asar\preload.bundle.js:88:702) at [REDACTED]\resources\app.asar\preload.bundle.js:88:798 Caused by: Error: createProxyAgent: all=true lookup is not supported

workaround: if you change the proxy settings from a fwdn to the ip-address the signal client can connect again!

there seems to be a bug in the name resolution.

a quick fix would be great! :-) thx

i can confirm that this works! Thanks!

[Ockenheimer]

Can confirm too.
Thanks a lot from Mainz @grufocom

[oijn]

Can also confirm connection issue & temporary mitigation measure with https_proxy env var with Linux:

========= System info =========
App version: 7.2.0
Environment: production
Linux version: "KDE neon 6.0"
Node version: 20.9.0
OS version: #25~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Feb 20 16:09:15 UTC 2
Time: 1710408490560
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/7.2.0 Chrome/122.0.6261.70 Electron/29.1.0 Safari/537.36

[RegularAdrian]

Can also confirm that as of 7.2.0 (noticed this from Beta) that on Mac, proxies were an issue.

Can also confirm that the workaround of using IP address instead of the domain appears to work. So does appear to be an issue with name resolution.

[Huuuze]

This bug emphasizes the need for native proxy support. If native proxy support were added to the app, it'd be tested and bugs like this one would not likely be released in the wild.

[cboling2]

Me too!
Running Debian 12.
I launch signal-desktop-beta w/ a script that sets proxy env vars (using squid w/ authentication)
I can't guarantee what the last version I last used that worked (I didn't track updates that carefully, but last communication on the PC in question was Feb26), but I do know that 7.2.0-beta.2 & 7.3.0-beta.1 both exhibit the regression.

[TheNetworkIsDown]

You can switch to using a pac file. It wasn't working before but it is now working.

[aureq]

@TheNetworkIsDown I didn't think Signal was actually ready a proxy.pac but it does. Unfortunately, setting an IP address instead of a hostname doesn't work either.

[TheNetworkIsDown]

@aureq Not sure what u mean. Unfortunately, there is no standard (like RFC) concerning the content of those env variables. It's not even clear if the variable name themselves should be in upper or lower case. From many apps I know that proxy support, especially (interactively) authenticated proxy or PAC, is abyssimal. Simply specifying an IP or hostname is the absolute minimum that should always work.

[aureq]

@TheNetworkIsDown I agree with your latest sentence. Some have suggested to use an IP address instead of a hostname, and this is what I tried to set in my proxy.pac, but unfortunately this didn't work.

[TheNetworkIsDown]

@aureq No, the workaround is setting an IP address in the env variable directly. The pac file works either way. In case you use a pac file and it "doesn't work", what do the logs say? What does pactester say? If it "doesn't work" you should try to find out why it "doesn't work" or at least provide information what you did exactly so that someone can help.

[TheNetworkIsDown]

@aureq well if you think the pac file "doesn't work" you should probably open another issue with all the necessary information, as this is issue is not about pac files.

[microwan]

with ip adress , it is working , thank for the tip , and you save me ;-)

[richlv]

Wait, you can point it at pac? How, with the http[s]_proxy (lowercase, the mentioned uppercase seems to be misunderstanding of some users, mostly)?

As @Huuuze mentioned, this shows that proper proxy support with documentation would help a lot. Yes. the desktop Signal is not working for me for days...

[TheNetworkIsDown]

@richlv see #6631 for an example

[richlv]

Thanks, that would be so wonderful to see in the official documentation.
For the record, changing to IP addresses helped here as well. To avoid obscuring the endpoint, a quick hack (Mac):

export http_proxy=http://$(dig +short host):8080; export https_proxy=http://$(dig +short host):8080; open -a Signal

[cboling2]

I confirm that specifying IP addr instead of host name makes it work again for me. Thanks!

[caramdache]

It seems 7.5.0 has broken proxies again. Had to go back to 7.2.0, but of course Signal tells me that this version has expired. I wish the obsolesence policy was a little more use friendly.

[RealLau]

It seems 7.5.0 has broken proxies again. Had to go back to 7.2.0, but of course Signal tells me that this version has expired. I wish the obsolesence policy was a little more use friendly.

bro, where to download pre build versions?

[ichEben]

can confirm that it's broken again.
The only Information in the logs:

WARN 2024-04-16T21:21:45.100Z SocketManager: authenticated socket connection failed with error: Error: Connection timed out
at [REDACTED]\resources\app.asar\preload.bundle.js:68:4534
at Timeout._onTimeout ([REDACTED]\resources\app.asar\preload.bundle.js:21:6507)
at listOnTimeout (node:internal/timers:573:17)
at process.processTimers (node:internal/timers:514:7)
INFO 2024-04-16T21:21:45.101Z SocketManager: reconnecting authenticated socket after 1000ms
ERROR 2024-04-16T21:21:45.101Z GET (WS) https://chat.signal.org/v1/config 0 Error
ERROR 2024-04-16T21:21:45.101Z GET (WS) https://chat.signal.org/v1/config 0 Error

[RegularAdrian]

I can also confirm that it's broken again (even with an IP address used instead of a hostname) on 7.6.0-beta.1

Getting the same log results as ichEben

[richlv]

Can confirm complete breakage with 7.5.0.
Trying to draw their attention on Mastodon, so far no luck:
https://mastodon.social/@richlv/112286212804377565

[ayumi-signal]

Hi! We released a fix in prod 7.5.1 and beta v7.6.0-beta.3 which both include the proxy fix, please try them.

As this issue pertains to an old version and previously resolved, future discussion can be consolidated to this topic:
#6857

[aureq]

@ayumi-signal The fix implemented in 7.5.1 appears to be working fine for me. Thank you for fixing Signal on desktop.