Reconnect if IP is not accessible

[From discord](https://discord.com/channels/1135646343776456765/1308367199727128649/1308961509573132339)
I’m not a web developer, so I haven’t really dug into the codebase to fully understand the implementation yet, but I definitely plan to in the future to be able to contribute more effectively.

Right now, I’m testing `mavlink-server` in one of our applications and noticed some behavior I wanted to clarify. I’m not sure if I’m missing something, so any insights would be appreciated!

Here’s my setup:
- **CubeOrange** connected to an **Raspberry Pi** via serial.
- The Pi is connected via Ethernet to two 4G routers (running VPN).
- I want `mavlink-server` to forward the MAVLink data to **4 separate UDP endpoints**.

I’ve configured the Pi to start up `mavlink-server` on boot with this command:
```
mavlink-server serial:/dev/ttyS0:115200 udpclient:192.168.0.21:11999 udpclient:192.168.0.21:10001 udpclient:192.168.0.22:10002 udpclient:192.168.0.22:21999
```

The issue:
- When I power cycle the device, the Cube and Pi boot up quickly, but the 4G/VPN routers take a minute or two to get online.
- Once the routers are online (confirmed they’re up), `mavlink-server` doesn’t reconnect to my GCS everytime sometimes one endpoint connects and other doesn't.
- If I manually restart `mavlink-server`, it immediately connects all endpoints and works fine. I have attached 2 logs 00 was on power cycle where one connection was successful and other wasn't, and log 01 was after restart mavlin-server service which worked fine.

I understand I can write a script to wait for the 4G to come online before starting `mavlink-server`, but I’m curious if there’s any built-in behavior for retrying connections that I might be missing. Or is there a setting I should configure to handle this better?

Also, I’ve tested the exact same setup with **MAVProxy** using the following command:
```
mavproxy.py --master=/dev/ttyS0:115200 --out 192.168.0.21:11999 --out 192.168.0.21:10001 --out 192.168.0.22:10002 --out 192.168.0.22:21999
```
The same behavior persists with MAVProxy.