[Bug] Dubbo 3.3.5 fails to start with Nacos 3.x due to removed /v1/ns/operator/switches API

[LenoMinkus]

Pre-check

• I am sure that all the content I provide is in English.

Search before asking

• I had searched in the issues and found no similar issues.

Apache Dubbo Component

Java SDK (apache/dubbo)

Dubbo Version

Item	Version
Dubbo	3.3.0
Nacos Server	3.0.2
JDK	openjdk-17
OS	Windows

Steps to reproduce this issue

1.Start Nacos 3.0.2 in standalone mode:
docker run -d -p 8082:8848 -p 8083:9848
-e MODE=standalone nacos/nacos-server:3.0.2
Configure Dubbo application.yml:
dubbo:
config-center:
address: nacos://localhost:8082
registry:
address: nacos://localhost:8082
metadata-report:
address: nacos://localhost:8082
Start the Dubbo application.

What you expected to happen

Application starts successfully with logs:
Successfully connected to nacos config server ...

Anything else

Actual Behavior
Logs repeatedly print:
Failed to connect to nacos config server. Server status: DOWN. Config Service Available: true.
Root Cause
Dubbo uses GET /nacos/v1/ns/operator/switches to determine the server status.
Nacos 3.x has removed this endpoint and returns 410 Gone, causing Dubbo to treat the server as DOWN.

Are you willing to submit a pull request to fix on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zrlw]

could you provide a pr?

[lingyufei]

I didn't get any error when starting up. using Dubbo 3.3 latest + Nacos v3 latest.

From the provided log, this error is from Nacos config module. However, I suppose Nacos Config Server status is not checked by using /nacos/v1/ns/operator/switches which is a HTTP API for naming service module. Also, Nacos Config Server status is checked by GRPC connection as default, not HTTP request.

Are you starting your APP in NACOS persistent mode? Only the APP in persistent mode uses the HTTP API. The default is in ephemeral mode, which uses GRPC.