Bug: IpStrategy from the panel has no effect on the default (freedom) outbound — it's hardcoded to UseIPv4v6, and even the fallback DNS query strategy ignores it
Summary
The panel can push an IpStrategy value (e.g. prefer_ipv6) to the node via GetServerConfig, and core/outbound/build.go does compute a corresponding Xray ipStrategy string ("prefer_ipv6" → "UseIPv6v4", see build.go:29-38). However, this computed value is never actually applied to the outbound that handles normal proxied traffic, so the setting has no observable effect on which IP family the node prefers when dialing out to a domain-name destination.
Root cause (two separate gaps)
-
Default outbound DomainStrategy is hardcoded, independent of any config:
core/outbound/outbound.go:19-21 (buildDefaultOutbound, the freedom outbound used for all normal proxied traffic egress):
proxySetting := &coreConf.FreedomConfig{
DomainStrategy: "UseIPv4v6",
}
This is a fixed literal — it never reads serverconfig.Data.IPStrategy or the ipStrategy variable computed in build.go. DomainStrategy on the freedom outbound is what actually controls dial-order preference between resolved IPv4/IPv6 addresses for real user traffic, so this is the dominant setting for the reported behavior, and it's completely disconnected from the panel-configured strategy.
-
The default DNS server's QueryStrategy also ignores the computed ipStrategy, using a separate variable driven only by hasIPv6:
core/outbound/build.go:48-63:
queryStrategy := "UseIPv4v6"
if !hasIPv6 {
queryStrategy = "UseIPv4"
}
coreDnsConfig := &coreConf.DNSConfig{
Servers: []*coreConf.NameServerConfig{
{Address: &coreConf.Address{Address: xnet.ParseAddress("localhost")}},
},
QueryStrategy: queryStrategy, // not `ipStrategy`
}
The ipStrategy variable computed from serverconfig.Data.IPStrategy (build.go:29-38) is only ever applied to admin-configured custom DNS server entries later in the same function (inside if dnsConfig != nil { ... QueryStrategy: ipStrategy ... }). When no custom DNS servers are configured (the common case — just the default localhost entry), the panel's IP strategy setting is never consulted at all, even at the DNS layer.
Net effect: as currently implemented, there is no code path by which a panel-supplied IpStrategy value changes the IP family preference used for actual proxied traffic. The field is read and switched on (build.go:29-38) but the result is discarded.
Suggested fix
- In
buildDefaultOutbound (core/outbound/outbound.go), accept the resolved ipStrategy string as a parameter and set FreedomConfig.DomainStrategy from it instead of the hardcoded "UseIPv4v6".
- In
build.go, use the same ipStrategy variable (not the separately-computed queryStrategy) for the default/base DNS server's QueryStrategy, so it's consistent regardless of whether custom DNS servers are configured.
Related
This compounds a separate panel-side bug where IpStrategy isn't even sent to the node in the first place — filed at perfect-panel/server. Both need fixing for the per-node "prefer_ipv6" style override to actually work end-to-end.
Environment
Found while running a self-hosted ppanel-server + ppanel-node deployment (the github.com/wyx2685/xray-core replace fork, go.mod pin v1.260327.0-era). No sensitive data included; happy to provide more detail if useful.
Bug:
IpStrategyfrom the panel has no effect on the default (freedom) outbound — it's hardcoded toUseIPv4v6, and even the fallback DNS query strategy ignores itSummary
The panel can push an
IpStrategyvalue (e.g.prefer_ipv6) to the node viaGetServerConfig, andcore/outbound/build.godoes compute a corresponding XrayipStrategystring ("prefer_ipv6"→"UseIPv6v4", seebuild.go:29-38). However, this computed value is never actually applied to the outbound that handles normal proxied traffic, so the setting has no observable effect on which IP family the node prefers when dialing out to a domain-name destination.Root cause (two separate gaps)
Default outbound
DomainStrategyis hardcoded, independent of any config:core/outbound/outbound.go:19-21(buildDefaultOutbound, thefreedomoutbound used for all normal proxied traffic egress):This is a fixed literal — it never reads
serverconfig.Data.IPStrategyor theipStrategyvariable computed inbuild.go.DomainStrategyon the freedom outbound is what actually controls dial-order preference between resolved IPv4/IPv6 addresses for real user traffic, so this is the dominant setting for the reported behavior, and it's completely disconnected from the panel-configured strategy.The default DNS server's
QueryStrategyalso ignores the computedipStrategy, using a separate variable driven only byhasIPv6:core/outbound/build.go:48-63:The
ipStrategyvariable computed fromserverconfig.Data.IPStrategy(build.go:29-38) is only ever applied to admin-configured custom DNS server entries later in the same function (insideif dnsConfig != nil { ... QueryStrategy: ipStrategy ... }). When no custom DNS servers are configured (the common case — just the defaultlocalhostentry), the panel's IP strategy setting is never consulted at all, even at the DNS layer.Net effect: as currently implemented, there is no code path by which a panel-supplied
IpStrategyvalue changes the IP family preference used for actual proxied traffic. The field is read and switched on (build.go:29-38) but the result is discarded.Suggested fix
buildDefaultOutbound(core/outbound/outbound.go), accept the resolvedipStrategystring as a parameter and setFreedomConfig.DomainStrategyfrom it instead of the hardcoded"UseIPv4v6".build.go, use the sameipStrategyvariable (not the separately-computedqueryStrategy) for the default/base DNS server'sQueryStrategy, so it's consistent regardless of whether custom DNS servers are configured.Related
This compounds a separate panel-side bug where
IpStrategyisn't even sent to the node in the first place — filed at perfect-panel/server. Both need fixing for the per-node "prefer_ipv6" style override to actually work end-to-end.Environment
Found while running a self-hosted
ppanel-server+ppanel-nodedeployment (thegithub.com/wyx2685/xray-corereplace fork,go.modpinv1.260327.0-era). No sensitive data included; happy to provide more detail if useful.