Invalid ip address

Help IPFS Desktop
1

I wanted to try this out but it failed at the first hurdle. Any ideas?

Windows 10.0.19045 (22H2)

Clean install of ipfs-desktop-setup-0.47.0-win-x64.exe without error.

Click Finish

“IPFS Desktop has shutdown because of an error. You can restart the app or report the error to the developers, which requires a GitHub account.”

I see no mention of this anywhere so I can only assume there is an issue with my machine.

%appdata%\IPFS Desktop\config.json:

{“ipfsConfig”: {“path”: “”,“flags”: [“–agent-version-suffix=desktop”,“–migrate”,“–enable-gc”]},“language”: “”,“experiments”: {},“binaryPath”: “”,“internal”: {“migrations”: {“version”: “0.47.0”}},“automaticGC”: true,“openWebUIAtLaunch”: true}

%appdata%\IPFS Desktop\error.log

2025-12-17T03:13:22.049Z error: invalid ip address
2025-12-17T03:17:07.486Z error: invalid ip address
2025-12-17T23:49:55.289Z error: invalid ip address

There is also a combined.log which I can post if anyone is interested. It starts like this:

2025-12-17T03:13:20.838Z info: [meta] logs can be found on C:\Users\Glenn\AppData\Roaming\IPFS Desktop
2025-12-17T03:13:21.001Z info: Running migration: >=0.11.0
2025-12-17T03:13:21.016Z info: Running migration: >0.13.2
2025-12-17T03:13:21.043Z info: Running migration: >=0.17.0
2025-12-17T03:13:21.056Z info: Running migration: >=0.20.6
2025-12-17T03:13:21.553Z info: [ctx] getting getIpfsd
2025-12-17T03:13:21.554Z info: [ctx] Could not find property getIpfsd
2025-12-17T03:13:21.609Z info: [ctx] setting startIpfs
2025-12-17T03:13:21.609Z info: [ctx] No promise found for startIpfs
2025-12-17T03:13:21.609Z info: [ctx] Resolving promise for startIpfs
2025-12-17T03:13:21.610Z info: [ctx] setting stopIpfs
2025-12-17T03:13:21.610Z info: [ctx] No promise found for stopIpfs
2025-12-17T03:13:21.610Z info: [ctx] Resolving promise for stopIpfs
2025-12-17T03:13:21.610Z info: [ctx] setting restartIpfs
2025-12-17T03:13:21.610Z info: [ctx] No promise found for restartIpfs
2025-12-17T03:13:21.610Z info: [ctx] Resolving promise for restartIpfs
2025-12-17T03:13:21.610Z info: [ctx] setting getIpfsd
2025-12-17T03:13:21.610Z info: [ctx] Resolving promise for getIpfsd
2025-12-17T03:13:21.610Z info: [ipfsd] start daemon STARTED
2025-12-17T03:13:21.706Z info: [analytics] init...
2

Thank you for reporting this.

It could be one of two things:

3

I tried for several hours yesterday and gave up. Came back to it today, decided to take a different route by uninstalling the desktop and installing the (cli?) version. Much googling and trying different ideas, most of it forgotten in the fog of trying to get it to work. Fiddling with the firewall, the router, ip forwarding, check your ips, maybe a different port, some other app using the port, the usual stuff, endless rebooting of pc and router. Nothing is making this mysterious invalid ip go away. So I’m staring at the config where it says ““API”: “/ip4/127.0.0. 1/tcp/5001”, toggle it to 5002, didn’t work back to 5001, nothing, and then I noticed a space right in the middle of that 127.0.0. 1 address. I said to myself, “that’s not a valid ip address”. I corrected it and the daemon started!

So I’m thinking, surely that can’t have been in the distribution package… can it?

What I didn’t do until later today was try an install on a different computer. Nearly identical Win10 22H2 installation. This went without a hitch and it all started up cleanly. So I’m rather perplexed about how the config got that way.

Having read the issue #3035 above I can see that a dodgy string replacement function could indeed create what I saw. Why it failed on this machine is the mystery.

Oh, I went through the active and listening ports on that machine a bunch of times and the ports in question were not in use elsewhere.

I’m happy to do some more testing if you want.

4

More information: I remembered the “kubo” wanted to do an upgrade when it first ran so I had a look in the .ipfs folder and found several files:

config.15-to-16.bak

config.16-to-17.bak

config.17-to-18.bak

I was wrong earlier about the config line in question; it’s not the API line, it’s the Gateway line:

“Gateway”: “/ip4/127.0.0 .1/tcp/8081”,

and the space was carried through in each upgrade.