Hello. I am the developer of Xlarva and we recently released the URL Filter feature to public and it works as intended. We deployed the PIR server with the help of Claude and finished the long onboarding process. We have not encountered the similar problems as you, so it might be that you have issues in the onboarding process? I downloaded Adguard mini, enabled System-wide protection and analyzed this problem with the help of Claude, and this is his anwser: My conclusion is that the failure sits in the OHTTP relay configuration Apple publishes for AdGuard's hosts, not in macOS 27.2 as such. On the same Mac and OS build (27.2, 26B123), networkserviceproxy holds a list of oblivious target hosts that appears to come from Apple and is the same for every device: it includes our PIR host and four other third-party PIR deployments, but no adtidy.org host at all. Because there is no relay entry for pir-issuer.adtidy.org (or pir-service.adtidy.org), the privacy proxy has no agent to send the request through, and under 27.2's proxy strict fail closed the request fails at 0 ms with proxy:children_failed, which surfaces as serverSetupIncomplete. AdGuard's own side looks complete (the apple-url-filter DNS TXT records and NSPIRConfiguration are in place), so the likely gap is that these two hosts' relay onboarding was never completed or never propagated to devices. That has to be fixed on Apple's side and can't be fixed by an app update. Why the same build works on 27.0 is unconfirmed; one possibility is that 27.0 fell back to a direct connection when no relay was configured. I am happy to assist you with this problem.

Thanks, Quinn! Did you try setting the allowFailover property to false? I have now. It reads false by default (matching the header comment, "Failover is not allowed by default"), and setting it to false explicitly makes no difference: the QUIC connection still goes direct. Results on macOS 27.0.1 (26A434), with the proxy set via NWParameters.PrivacyContext.proxyConfigurations: QUIC, working SOCKS5 server, allowFailover = false: .ready, connected to the origin directly; the server receives nothing. QUIC, proxy pointing at a port nothing listens on, allowFailover = false: .ready, connected to the origin directly. TLS, same dead proxy, allowFailover = false: stays in .waiting with ECONNREFUSED. TLS, same dead proxy, allowFailover = true: .ready, connected to the origin directly, as documented. So by your reasoning this is a bug. I'll add these results to FB24760235. This should be reflected in the usedProxy property of the connection establishment report. It is, thanks. For the QUIC connections usedProxy is false and proxyEndpoint is nil, so an app can at least detect it after the fact. One more detail that may help whoever picks up the bug: proxyConfigured is false as well. The header says that property is true when "a proxy configuration applied to the connection, even if the connection did not end up using a proxy", and the TLS failover case above does report proxyConfigured == true with usedProxy == false. For QUIC both are false, so it looks like the SOCKS5 configuration is treated as not applicable to QUIC and dropped before establishment, rather than tried and failed over. That would also explain why allowFailover has no effect.