Hi… No, traffic to .internal addresses bypasses the Fly Proxy completely, and hence it won’t be affected by any of this.
In general, there is a bit of awkwardness in Flycast terminology. There are two different compartments involved, , the one making requests and the one receiving them.
All that docs quote is saying is that secretApp is in the latter compartment only: it cannot send to that specific destination address (e.g., fdaa:3:abcd:0:1::c) itself, even though it will indirectly receive things that were sent there.
|
| fdaa:3:abcd:0:1::c
| /
secretApp ← Fly Proxy ← public server
| \
| fdaa:3:abcd:a7b:1234:f00f:1dd3:2
|
Hope this helps!
Aside: An app can have multiple Flycast addresses, each with different “making requests” linkages. So, if you did ever find yourself wanting to use .flycast within secretApp, you would just invoke fly ips allocate-v6 --private a second time (with a different --network).
$ fly ips list
VERSION IP
v6 fdaa:3:abcd:0:1::c ← main network
v6 fdaa:8:9876:0:1::2 ← secret network
That first one can be used (to make requests) by machines that start with fdaa:3:abcd:* in their own address, and the second one by machines with fdaa:8:9876:*.
The Fly.io platform is versatile about these things to the extent that its docs are still having a hard time catching up, in my opinion…