How to add external IP to IPFS swarm announcing list

I have an instance on google cloud which I installed IPFS on it. my issue is when I run it only announce local ip and internal ip in swarm list and can’t detect external (floating) IP. How can announce external IP?

I don’t know. I have a node behind NAT and after few minutes it adds correctly the exterior IP (if the ports are accessible) to the announce. No idea about the mechanism behind it, but it is automatic (in my case) after some time.

You can announce external IPs that IPFS is unable to infer by specifying them in the config. Specifically, the Addresses.Announce section.

For example, if you wanted to announce on port 4001 (assuming you’re using the default swarm port), you would specify it as shown below.

"Announce": [


1 Like

Good Day all. I have added these lines to the config file but either they are not being used when the daemon starts or I am looking in the wrong place for verification. x’s inserted in this post to block who knows what.
“Addresses”: {
“API”: “/ip4/”,
“Announce”: [
“NoAnnounce”: [
“Gateway”: “/ip4/”,
“Swarm”: [
Starting the daemon produces the usual status messages and appears to ignore the config data. Specifically it still shows
Swarm listening on /ip4/12.208.x.xx/tcp/4001
as the only reference to an outside address. Which it accurately gets from the external firewall, but it is not the address that it should be advertising, based on the config. I know that the daemon is using this config from the many punctuation errors that cause the daemon to fail to start. - Thanks.

What does it show in the list of Swarm announcing /ipx/x/tcp/x addresses when starting the daemon?

There is no line for swarm announcing or no-announcing.

As far as I can tell, the daemon never recognized the “Announce” and “No-Announce” entries in the config. After a few days, it came up with the correct outside facing ip address. Assuming it just asked around. :slight_smile:

@stebalien is this a known bug? You mentioned that behavoir in the other thread, but not the Announce/NoAnnounce configuration.

I have noticed when others post the messages issued when the daemon starts, that there is a line for “Announce”. Thinking it gets that from the config file. Maybe I hit that void between being syntactically correct, so the daemon starts, but still not being recognized.

According to the documentation the syntax should be right.

Whatever is put on Announce should become what is announced.

If that does not happen, you are not editing the right config that is being used by the daemon (i.e. you are editing the config for your local user but run ipfs as root), or your config is mangled in a way that it is still parseable but does not parse into the right config options. From the looks, the config excerpt pasted here seems ok.

To double check, change some other configuration option, like the gateway port. Does it take effect upon re-start?

That was suggested earlier and I made a punctuation error in the file and the daemon load failed. Change the punctuation back and it loads. That was consistent over several cycles, so I don’t suspect another copy. While it does consistently load now with the right public IP, there is no line in the load display that indicates any special announce config. I think it just figured the NAT out.

Please check ipfs id and/or ipfs swarm addrs local. When IPFS starts, it prints the interfaces/addresses it’s listening on, those are all addresses on your local machine.

Both indicate correct addresses now, and queries from the outside do work. But when I first started it had a choice of 2 public facing addresses to pick from and picked the wrong one. So I was trying to use ANNOUNCE to tell it which one. Never could get announce to obviously work based on what the daemon start screen was providing. Since then it has figured out the right public address to use. But, I never saw any evidence that it used the ANNOUNCE/NOANNOUNCE segments in the config. The daemon does not error, just appears to ignore, as they don’t appear in the summary from daemon start. Hopefully it will stay latched on to the right address in future starts.