Nodes have problems with get more that 3 peers

[leonprou]

@Andrew-Pohl's. suggesting that too lengthy nodes.json files can be the cause.

[henry-hz]

I deleted the .json and restarted, and still with the same issue

[CursedDevelopment]

I can confirm that my nodes have never been able to concurrently stay connected to more than 3 peers over the past year. Usually it's just one.

An upgrade to OpenEthereum over Parity did not make a difference.
Changing parameters that should affect peer connections have no effect.
The problem is completely independent of the mentioned nodes.json.

After restarting the node it can take anywhere from 30 minutes to 8 hours until a live peer is found. It usually goes up to 3 and eventually settles on just one which will keep the connection alive.

This is not only an annoyance, but also causes a severe trust issue for everyone using the network.

[Andrew-Pohl]

I can confirm that my nodes have never been able to concurrently stay connected to more than 3 peers over the past year. Usually it's just one.

An upgrade to OpenEthereum over Parity did not make a difference.
Changing parameters that should affect peer connections have no effect.
The problem is completely independent of the mentioned nodes.json.

After restarting the node it can take anywhere from 30 minutes to 8 hours until a live peer is found. It usually goes up to 3 and eventually settles on just one which will keep the connection alive.

This is not only an annoyance, but also causes a severe trust issue for everyone using the network.

This issue seems to be fixed looking at https://health.fuse.io

Few questions:
How are you launching the node?
Are you running time sync?
Where is the node based?
You mention you used OE can you try using our image https://hub.docker.com/layers/fusenet/node/1.0.0_OE/images/sha256-dbd5e8b7aeb36141e829d63d05a1efb1fc3f729d1e979fb43653811b3e409c40?context=explore

[CursedDevelopment]

Time on the servers is kept in sync using chronyd. The nodes are based in Norway with symmetric 1GBit connections.
Currently I have 3 servers there running fuseio nodes on OpenEthereum using a config file and no other command line parameters.

[parity]
mode = "active"
base_path = "$HOME/.ethereum"
chain = "/home/fuse/.ethereum/spec.json"
keys_path = "$BASE/fusekeys"

[network]
interface = "all"
bootnodes = ["enode://e21e2053005e40653d055fc01a07768357749d27d630702c203b1a3c00bdf219a104b1d88368173bdff1cd36b836fa89f10a70399aca72223c5d117881f4ecdd@18.184.21.11:30303","enode://b30277f57a4b0fef9d8093b6bfb6505caa2ab67f3b9279a5468ac14b4012be5898c74266a435f8a412a472b5d1679876e95c2bc924f72ec03b2fe18378182dd1@18.184.223.179:30303","enode://7bc2e851cad345437984d6550b1b98d7029b694f2793e2c592637a793b243760060a5a3e00d6212b75f1c534a97b41d532221071242d01116e9ff3c8dcc95672@95.217.1.4:30303"]

[rpc]
apis = ["web3", "eth", "pubsub", "net", "parity", "parity_pubsub", "traces", "rpc", "personal", "parity_accounts", "secretstore"]
port = 8547

[websockets]
apis = ["web3", "eth", "pubsub", "net", "parity", "parity_pubsub", "traces", "rpc", "personal", "parity_accounts", "secretstore"]

[ipc]
path = "$HOME/.ethereum/jsonrpc.ipc"
apis = ["web3", "eth", "pubsub", "net", "parity", "parity_pubsub", "parity_accounts", "traces", "rpc", "personal", "secretstore"]

[secretstore]
disable = true

[footprint]
scale_verifiers = true

[misc]
log_file = "$BASE/debug.log"
logging = "own_tx=trace"

the bootnodes and spec.json were taken from this project's config directory. The systems are firewalled but configured to let traffic on the configured network port through on their respective external IPs.
While I cannot use docker on these machines, I have run the original Parity in the past. That's until Parity Technologies stopped maintaining the project early last year. Outside of several trials I've run, the relevant sections of the configuration always were and are the same as in your project.

If by fixed you are referring to the fuse health status listing 57/59 active nodes, I don't know what to tell you, I've never seen anything exceeding this:
2021-09-16 00:20:39 Worker Client1 INFO import 3/25 peers 4 MiB chain 0 bytes queue RPC: 0 conn, 0 req/s, 331 µs
independent of version and settings. What I find interesting is that the pings to your health service are all very low, meaning all nodes are geographically close. I don't know if high latency clients would be rejected, but if so, maybe there are just very few nodes in Europe? But then again both Parity and OpenEthereum observe the same issue on Ethereum and Ethereum Classic. Luckily, for those there are alternative clients available that manage peers just fine.