I am struggling to expose my rpc node publicly (wss://vit.fdn.org/ws) with duniter v2s and nginx in docker) 
With the provided docker-compose for duniter and the nginx config example, as is.
By default, duniter listen to localhost (it refer to the duniter container).
But in nginx config I can not use localhost, as it refer to the nginx container.
Can somebody with a working nginx/duniter rpc node can show me his docker-compose and nginx config ?
repalce localhost by 0.0.0.0 in your compose.
Ou juste, ne pas préciser d’ip c’est pareil.
services:
duniter-rpc:
image: duniter/duniter-v2s:sha-f442e6eb
restart: unless-stopped
ports:
- "9944:9944"
volumes:
- ./duniter-data:/var/lib/duniter/
environment:
- DUNITER_CHAIN_NAME=gdev
command:
- "--rpc-cors=all"
- "--rpc-methods=Unsafe"
- "--pruning=archive"
- "--name"
- "poka-rpc"
root@axiom2-nginx:/home/poka/nginx/133# cat gdev.p2p.legal.conf
upstream gdev.p2p.legal.rpc-http {
server 192.168.9.33:9933; #Production
}
upstream gdev.p2p.legal.rpc-websocket {
server 192.168.9.33:9944; #Production
}
server {
server_name gdev.p2p.legal;
listen 443 ssl;
listen [::]:443 ssl;
include includes/ssl.conf;
include includes/errors.conf;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
proxy_redirect off;
proxy_buffering off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
proxy_read_timeout 90;
location /http {
proxy_pass http://gdev.p2p.legal.rpc-http;
proxy_http_version 1.1;
}
location /ws {
proxy_pass http://gdev.p2p.legal.rpc-websocket;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_http_version 1.1;
proxy_read_timeout 1200s;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
}
ssl_certificate /etc/letsencrypt/live/gdev.p2p.legal/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/gdev.p2p.legal/privkey.pem;
error_log /var/log/nginx/gdev.p2p.legal_error.log;
access_log /var/log/nginx/gdev.p2p.legal_access.log;
}
server {
listen 80;
server_name gdev.p2p.legal;
include includes/letsencrypt.conf;
if ($host = gdev.p2p.legal) {
return 301 https://$host$request_uri;
}
return 404;
}
Hope this is helpfull.
Thanks for the help, but the problem was between the chair and the keyboard… 
wss://vit.fdn.org:9944/ws was configured in my nginx, but I was desperately trying to connect to wss://vit.fdn.org/ws.
Then I figured out that wss url without a port is resolved to wss://vit.fdn.org:443/ws
…Ooops.
So I configured wss://vit.fdn.org:443/ws in nginx and everything is fine.
I even do not need to add --ws-external to allow access by the docker host IP on substrate…
Sorry for the noise in the subject,
and Happy New Year to all devs in the Ğ1 project ! 
wss://vit.fdn.org/ws RPC mirror node is officially publicly available. I hope.
Duniter validator is listening on port 30334, there is no need for public address
--public-addr <PUBLIC_ADDR>...
The public address that other nodes will use to connect to it.
This can be used if there's a proxy in front of this node
Available with https://polkadot.js.org/apps/?rpc=wss://vit.fdn.or/ws. Now you have to become smith 
I have sometimes unexpected power failure from the power provider, so I will study how to become smith and if I have too much failures, may be I will not stay smith (my server is at home)…
I have opened 9615 port for Prometheus if you need it. Tell me if it works.
The goal is to learn what a smith need to know to be able to share with other smith and to make sure that the smith licence is fine. There is not pb if ĞDev is not very stable as it is a dev network. We will test stability with ǦTest later.
I do not know prometheus monitoring, I have to learn that.
Please
change the --name option to make it easier to know which node belongs to who.
Duniter validator is listening on default port 30333 actually. And the docker-compose file maps it to the host’s port 30334. How is it that no public addr is needed while one is provided for the RPC service which is mapped to the default 30333 port on the host?
I think public address is never needed, it is only here to make things easier for bootnodes. Maybe @poka has a better understanding of this than me.
When trying to start a simple RPC node for testing I get this error:
2023-01-03 19:36:31 Duniter
2023-01-03 19:36:31 ✌️ version 0.3.0-f442e6eb161
2023-01-03 19:36:31 ❤️ by Axiom-Team Developers <https://axiom-team.fr>, 2021-2023
2023-01-03 19:36:31 📋 Chain specification: Ğdev
2023-01-03 19:36:31 🏷 Node name: pini-gdev-rpc
2023-01-03 19:36:31 👤 Role: FULL
2023-01-03 19:36:31 💾 Database: ParityDb at /var/lib/duniter/chains/gdev/paritydb/full
2023-01-03 19:36:31 ⛓ Native runtime: gdev-400 (duniter-gdev-1.tx1.au1)
2023-01-03 19:36:33 Cannot create a runtime error=Other("cannot create module: compilation settings are not compatible with the native host")
Error: Service(Client(VersionInvalid("cannot create module: compilation settings are not compatible with the native host")))
My server has an Intel Atom N28000 CPU. Should I build my own image for this to work?
Interesting, I know nothing about Docker. Is it supposed to deal with processor architecture issues ? Try building Duniter on your machine, it should work.
Thanks @vit.
Do I understand correctly that this problem should be solved by upgrading the Duniter Substrate fork so that it uses wasmtime >= 0.40.0?
In the mean time I’ll use the provided workaround: --wasm-execution interpreted-i-know-what-i-do.
Now my instance starts but spits this error every 2 ou 3 seconds:
2023-01-03 20:39:33 💔 The bootnode you want to connect provided a different peer ID than the one you expect: `12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r` with `12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB`:`Dialer { address: "/dns/gdev.p2p.legal/tcp/30334/p2p/12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r", role_override: Dialer }`.
12D3KooWMYJzk1FfBZjEAuEvwUnH2Luj5Bq4ouLX1tgZBPpFegaB
is the current @poka smith bootnode
12D3KooW9v5WsP38qU1kmafvA4CDw2vzYnFoWtdUqwonZtJK597r
comes from an other genesis (the one in master branch)
If you are building Duniter yourself, you have to use release/poka-chainspec-gdev5 branch.
Yes, just realized that. I’m still using the image I built. Reverting to the official one… It works!
Nice! I added you to the list, now we have to introduce you to the smith WoT ^^
I’ll experiment a bit with the configuration. Then there are chances I’ll propose some configuration changes to the docker image.
I started a validator node.
But I was not able to send my session keys because my identity is on a v1 account…
So I need to move my identity on a v2 account before becoming a smith.
I will continue to work on the v1 to v2 account move in Tikka, as it is a perfect use case for it.