[StrangePan][2.1.20][macOS] Authentication fails when HTTPS socket reaches FD 1024 with many ZIP mods
Posted: Sun Sep 27, 2026 9:26 am
Factorio version: 2.1.20 (build 87512, mac-arm64, Steam, Space Age)
OS: macOS 27.0.0
Hardware: Apple M4 Pro
Summary
Factorio authentication reliably stops working when enough ZIP mods are present in the mods directory for the HTTPS connection to receive file descriptor 1024.
The mods do not need to be enabled.
In my reproducible test:
In the failing case, lsof shows the HTTPS connection at FD 1024.
Removing one ZIP makes authentication work again. Adding it back makes it fail again.
Reproduction
I have a large collection of ZIP mods in the mods directory. Almost all of them are disabled; only the official mods are enabled.
I found a reliably reproducible working/broken configuration.
With 555 ZIP files present:
I then add one additional valid ZIP mod:
After restarting Factorio:
I remove only that ZIP and restart:
I add the same ZIP again and restart:
I reproduced this multiple times.
What happens
In the failing configuration, the verbose log shows Factorio attempting:
After exactly 60 seconds:
Factorio then attempts:
This also times out after 60 seconds.
Eventually:
So the problem already occurs during TLS/auth HTTP communication.
File descriptor observation
I captured while Factorio was in the failing state.
The HTTPS connection is assigned FD 1024:
The descriptors immediately around it are:
Factorio also keeps two open descriptors for many ZIP mods. For example, in the attached lsof output:
With the smaller working configuration, the HTTPS sockets were below the 1024 boundary (FD 1021/1022).
The FD 1024 boundary therefore appears to be the important difference between the working and failing configurations.
This does not appear to be caused by what-items-do-i-have
The same mod works when fewer ZIP files are present.
I also tested many different subsets of the mod collection. Different subsets can reach the failure at different ZIP counts.
Therefore, the important factor appears to be the number of open file descriptors rather than this particular mod or a specific number of ZIP files.
Expected behavior
Authentication and other HTTP networking should continue working when enough local ZIP mods are present that a network socket receives a file descriptor >= 1024.
Possibly related report
This appears very similar to the previously reported issue:
which was related to file descriptors exceeding FD_SETSIZE / select() limits.
Attachments
OS: macOS 27.0.0
Hardware: Apple M4 Pro
Summary
Factorio authentication reliably stops working when enough ZIP mods are present in the mods directory for the HTTPS connection to receive file descriptor 1024.
The mods do not need to be enabled.
In my reproducible test:
Code: Select all
555 ZIP mods -> authentication works
556 ZIP mods -> authentication fails
Removing one ZIP makes authentication work again. Adding it back makes it fail again.
Reproduction
I have a large collection of ZIP mods in the mods directory. Almost all of them are disabled; only the official mods are enabled.
I found a reliably reproducible working/broken configuration.
With 555 ZIP files present:
Code: Select all
555 ZIPs -> works
Code: Select all
what-items-do-i-have_1.4.3.zip
Code: Select all
556 ZIPs -> authentication fails
Code: Select all
555 ZIPs -> authentication works again
Code: Select all
556 ZIPs -> authentication fails again
What happens
In the failing configuration, the verbose log shows Factorio attempting:
Code: Select all
Downloading https://auth.factorio.com/tls-check/success
Code: Select all
CURL failed: code:28
Connection timed out after 60000 milliseconds
Code: Select all
https://auth.factorio.com/api-steam-login?api_version=6
Eventually:
Code: Select all
Failed to reach auth server: code(520) message(Connection timed out after 60000 milliseconds)
File descriptor observation
I captured
Code: Select all
lsofThe HTTPS connection is assigned FD 1024:
Code: Select all
factorio ... 1024u IPv4 ... TCP 192.168.110.40:63641->104.26.14.88:https (CLOSE_WAIT)
Code: Select all
1018 main-menu.ogg
1019 wind.ogg
1020 ValveIPCSHM
1021 world_base_wind.ogg
1022 unix socket
1023 unix socket
1024 HTTPS socket
1026 NPOLICY
1027 com.apple.netsrc
1028 unix socket
Code: Select all
waterfill-2_1.0.3.zip -> FD 1004 and 1005
what-items-do-i-have_1.4.3.zip -> FD 1006 and 1007
The FD 1024 boundary therefore appears to be the important difference between the working and failing configurations.
This does not appear to be caused by what-items-do-i-have
The same mod works when fewer ZIP files are present.
I also tested many different subsets of the mod collection. Different subsets can reach the failure at different ZIP counts.
Therefore, the important factor appears to be the number of open file descriptors rather than this particular mod or a specific number of ZIP files.
Expected behavior
Authentication and other HTTP networking should continue working when enough local ZIP mods are present that a network socket receives a file descriptor >= 1024.
Possibly related report
This appears very similar to the previously reported issue:
Code: Select all
[2.0.45] No multiplayer connectivity after 620 distinct mods
Attachments
- factorio-current-BROKEN-VERBOSE.log — verbose log from the failing run
- factorio-BROKEN-lsof.txt — lsof captured while Factorio was in the failing state
- screenshot of the authentication error