Network Connectivity Test network-connectivity-test
The Network Connectivity Test is a Cloud Manager diagnostic tool that lets you validate Advanced Networking and VPN configuration before you enable Advanced Networking on your environments and before you go live. Use it to verify that the hosts and ports AEM must reach, including internal or private endpoints, are reachable over the same connectivity path Advanced Networking will use.
The test runs from the egress proxy infrastructure that belongs to your program’s Advanced Networking setup, not from an Author or Publish pod. It uses the same outbound network path AEM uses when Advanced Networking is active. That design is especially useful for VPN scenarios: you can confirm DNS resolution, network routing, firewall rules, and service availability for private or on-premises systems before you go live.
For background on provisioning VPN, dedicated egress IP, or flexible port egress, see Configuring Advanced Networking for AEM as a Cloud Service.
When to Use This Tool when-to-use
- After Advanced Networking is created at the program level and before or while enabling it on environments.
- To validate VPN connectivity to private or on-premises systems you operate (for example, internal hostnames or private IP addresses).
- To narrow down DNS issues versus firewall or routing issues when a service does not respond as expected.
Prerequisites prerequisites
- A Cloud Manager program.
- Advanced Networking infrastructure already created for the program (see Configuring Advanced Networking).
How to Run a Test how-to-run-a-test
-
Sign in to Cloud Manager at my.cloudmanager.adobe.com and open your organization and program.
-
Open the Environments tab for the program. In the left sidebar, select Network Infrastructures.
-
On the Network Infrastructures page, locate your infrastructure in the table. Either select a row to open the testing experience, or open the row actions menu (
) and choose Test.
-
The Network Testing dialog opens. Enter Host and Port, select Test, and review DNS resolution, port open, HTTP connectivity, and reachability in the results area. Optional actions such as Copy to clipboard and recent test history appear in the dialog. See Understanding Results for how to interpret each section.
Input Fields input-fields
internal-api.example.com, 10.0.1.50443Steps test-steps
- Enter Host and Port.
- Select Test. Results usually appear within a few seconds.
- Optional: Use Copy to clipboard to capture the full JSON result (useful for support cases).
- Recent tests may be listed for quick re-runs.
Understanding Results understanding-results
The tool reports several dimensions. Together they describe whether the target is reachable from Advanced Networking and how HTTP-aware checks behaved.
DNS Resolution dns-resolution
ips: ["10.0.1.50"]error: "DNS resolution error: ..."Port Open port-open
Yes / trueNo / falseHTTP Connectivity http-connectivity
An HTTP/HTTPS request is attempted on every port. The tool always tries HTTPS first, then falls back to HTTP. If neither works, the result is mapped to a short, readable error message (see the table below).
Success Outputs
protocol: "https", status_code: 200, reason: "200 OK"protocol: "http", status_code: 301, reason: "301 Moved Permanently"Classified Error Outputs
"Not an HTTP/HTTPS service""The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity.""Connection refused""The port is not accepting connections. Verify the service is running and listening on this port.""Connection timed out""The connection timed out. Check firewall rules and network routing.""No IPs resolved for host"200, 301, 302, 403, 404, or 500) is a success signal for connectivity—it means the network path works. The status code reflects the service’s own response, not overall network health. For non-HTTP services, the tool indicates Not an HTTP/HTTPS service; use Port open and Reachability as the reliable indicators for those services.Reachability reachability
Multiple DNS Resolvers multiple-dns-resolvers
If your Advanced Networking infrastructure defines more than one DNS resolver:
- When all resolvers return identical results, you see a single consolidated result labeled
default. - When resolvers return different results, each resolver’s outcome is shown separately (labeled
resolver_1,resolver_2, and so on), with the resolver IP, so you can see which DNS server is causing the inconsistency.
Troubleshooting troubleshooting
The following scenarios pair what you are likely to see in the tool with steps to narrow down the cause. For full Copy to clipboard JSON that illustrates the same situations, see Example Outputs.
DNS Resolution Failed dns-failed
Output
The hostname did not resolve using your Advanced Networking DNS settings, so the tool cannot test the port. In the results view, DNS resolution shows an error string, and Reachability reports that DNS failed:
DNS Resolution: error: "DNS resolution error: ..."
Reachability: "Unreachable: DNS resolution failed"
Recommendations
- Verify the hostname is correct—check for typos and that you are using the intended DNS zone (the wrong zone is a common mistake).
- Ensure your DNS resolvers—those configured in the network infrastructure—are reachable from the Advanced Networking CIDR range (the same address space the tool and AEM use for outbound checks). If you rely on private DNS, those servers must be reachable through the VPN tunnel or within the network address space that routing exposes to Advanced Networking.
- Verify that your configured DNS servers can resolve the hostname — Advanced Networking uses only the resolvers defined in your network infrastructure setup, not public DNS (for example,
8.8.8.8). If your internal DNS has no record for that hostname, resolution fails. - For VPN setups: Confirm the DNS server IP addresses lie within the VPN address space (the remote network CIDR the tunnel is built for). Resolvers on a subnet that is not routed through the VPN tunnel are not reachable from Advanced Networking.
DNS Works but the Port Is Not Accessible dns-ok-port-blocked
Output
The tool can resolve the host, but TCP to the port does not succeed. A summary often looks like this:
DNS Resolution: ips: ["10.0.1.50"]
Port Open: No
Reachability: "Unreachable: Port not accessible"
Recommendations
- Review firewall and allow-list rules on the target service—incoming traffic from your Advanced Networking infrastructure CIDR range (and egress IP addresses AEM uses) must be permitted. If you use a VPN, include remote network CIDRs as your design requires.
- Verify the service is running and listening on the host and port you entered in the test.
- For VPN setups: Confirm the tunnel is up, routing reaches the target subnet, and the target address lies in the remote network address space carried over the VPN.
- On your infrastructure, review network security groups (NSGs), security rules, or equivalent that could block the port between Advanced Networking and the target.
- Confirm the port number—ensure the process is actually listening on the port you are testing.
Test Shows Reachable but AEM Does Not Connect reachable-but-aem-fails
Output
The connectivity check itself succeeds. A condensed summary often looks like this:
Port Open: Yes
Reachability: "Reachable"
That outcome means the path from Advanced Networking to the host and port you tested is open. It does not guarantee that AEM application traffic is using that path: when your code runs, service logs may still show no requests from the egress IP you expect.
Recommendations
- The application code must be configured to use the proxy. The connectivity test proves the network path works, but AEM must explicitly route requests through the Advanced Networking proxy (for example, via the
AEM_PROXY_HOSTenvironment variable). If the code makes direct connections without the proxy, traffic does not go through the Advanced Networking infrastructure. - Review proxy settings in your HTTP clients - HTTP clients should use the same proxy configuration (
AEM_PROXY_HOSTand port forwarding where applicable). - Verify the port forwarding configuration for Advanced Networking at the environment level: in
portForwards, each entry must mapportOrigtoportDeston the right target host.portOrigis the port your AEM application code connects to when it opens the outbound connection through the proxy.portDestis the actual port on the target service where the remote process is listening. The target host is the hostname or address of that service as used in the forward. All three must match how your application is written to connect. - Check
nonProxyHosts. If the target host is listed there, requests skip the proxy for that host and will not follow the Advanced Networking path you validated.
HTTP Shows an Error but Port Is Open http-error-port-open
Output
TCP succeeds, but the HTTP/HTTPS probe still reports a failure. A summary often looks like this:
Port Open: Yes
HTTP Connectivity: error: "Connection error: ..." or "Both HTTPS and HTTP failed. ..."
Reachability: "Reachable"
Recommendations
- The service may not speak HTTP or HTTPS — for example, raw TCP, gRPC, or another protocol. The HTTP probe can fail while
Port open: YesandReachability: Reachablestill confirm that the network path works. Use those fields as the source of truth for non-HTTP services. - Investigate TLS and certificate configuration. If HTTPS fails but HTTP succeeds (sometimes indicated by a note such as
HTTPS failed, HTTP succeeded), the service may have certificate problems or may only offer HTTP on that port.
Request Timeout timeout
Output
{ "error": "Request timeout" }
Recommendations
- Allow for service response time—the check uses a timeout of 5 seconds. Targets that answer slower than that will time out even when they are otherwise healthy.
- Account for network latency. On VPN connections, high latency or an unhealthy tunnel can push the round trip over the limit; review tunnel status and routing.
- Run the test again. One-off network glitches can produce a timeout that does not recur.
Example Outputs example-outputs
Successful HTTPS Test (e.g., Internal API on Port 443) example-output-successful-https
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"protocol": "https",
"status_code": 200,
"reason": "200 OK"
},
"reachability": "Reachable"
}
]
}
Successful Non-HTTP Service Test (e.g., Database on Port 5432) example-output-successful-non-http
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": true,
"http_connectivity": {
"error": "Not an HTTP/HTTPS service",
"note": "The service appears to be a non-HTTP service (e.g., database, message queue, or custom TCP). Use the port_open and reachability fields to verify connectivity."
},
"reachability": "Reachable"
}
]
}
DNS Resolution Failure example-output-dns-resolution-failure
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"error": "DNS resolution error: dial udp 10.0.0.2:53: i/o timeout"
},
"port_open": false,
"http_connectivity": {
"error": "DNS resolution failed"
},
"reachability": "Unreachable: DNS resolution failed"
}
]
}
Port Not Accessible (Firewall / Service Down) example-output-port-not-accessible
{
"resolvers": [
{
"name": "default",
"dns_resolution": {
"ips": ["10.0.1.50"]
},
"port_open": false,
"http_connectivity": {
"error": "Connection error: dial tcp 10.0.1.50:443: i/o timeout"
},
"reachability": "Unreachable: Port not accessible"
}
]
}
Important Notes important-notes
What This Test Does Not Do what-this-test-does-not-do
- The test does not run from inside an AEM author or publish pod. It runs from egress proxy infrastructure. That validates the network layer, not application-level proxy configuration in your code.
- It does not validate your AEM application’s proxy settings. Even when the result is
Reachable, AEM code must still be configured to use the proxy. - It does not validate environment-level port forwarding configuration by itself. It tests raw connectivity from the infrastructure path.
- It does not send custom payloads. HTTP tests issue a basic
GETrequest to/.
Response Time response-time
- Typical: about 2 to 3 seconds.
- Maximum: about five seconds timeout.
- All DNS resolvers and connectivity checks run in parallel.
HTTP vs Non-HTTP Services http-vs-non-http-services
The tool attempts an HTTP/HTTPS connection on every port. For non-HTTP services (for example, PostgreSQL on port 5432, MySQL on 3306, SFTP on 22, Redis on 6379), the HTTP check can fail with a connection error—this is expected. Rely on Port open and Reachability to confirm connectivity for those services.