TLS, Reverse Proxies, Context Paths, HTTP Settings, Network Boundaries, and Secure Exposure: Diagnostics, Failure Modes, Security, and Performance

1. Diagnose from the outside in, without destroying evidence

A failed package request can traverse a dozen layers. The safe method is to preserve the first failure, identify the layer that produced it, change one variable, and repeat the same controlled request. Clearing every cache, restarting every service, disabling TLS checks, and granting admin privileges may hide the symptom while leaving the real defect intact.

2. Ordered diagnostic sequence

3. Redirect loop and mixed-scheme links

A classic loop occurs when the edge accepts HTTPS but forwards HTTP while failing to tell Nexus that the original request was HTTPS. If an application or intermediary then redirects “HTTP” to HTTPS, the client returns to the same edge and repeats the cycle.

# Capture redirects without following them first.
curl -sS -D - -o /dev/null \
  --cacert lab.crt --resolve nexus.lab.test:8443:127.0.0.1 \
  https://nexus.lab.test:8443/some/path

# Then follow only with a bounded count while diagnosing.
curl -sS -L --max-redirs 5 -o /dev/null -w '%{url_effective} %{http_code}
' ...

Inspect X-Forwarded-Proto, Host, proxy redirect rules, and the Nexus context path before touching repository settings. Mixed HTTP/HTTPS links usually indicate the public request identity was reconstructed incorrectly.

4. Wrong Host or forwarded host

Virtual-host routing and generated redirects can depend on the external host. A proxy that replaces Host with 127.0.0.1:8081 can make the backend believe the internal endpoint is public. Preserve the external host unless your architecture deliberately uses another canonical host, and pass forwarded host information consistently.

5. Intentionally broken example: preserve a SAN mismatch

Do not “fix” a certificate error by disabling verification. Produce the mismatch deliberately and keep the original output.

# The lab certificate contains only DNS:nexus.lab.test.
# Intentionally request a different name mapped to the same socket.
set +e
curl --cacert "$LAB/cert/nexus.lab.test.crt" \
  --resolve wrong.lab.test:8443:127.0.0.1 \
  https://wrong.lab.test:8443/service/rest/v1/status \
  2>"$LAB/evidence/san-mismatch.txt"
rc=$?
set -e
printf 'curl exit=%s
' "$rc" | tee -a "$LAB/evidence/san-mismatch.txt"

# Repair: use the hostname that is actually in the SAN.
curl --fail --cacert "$LAB/cert/nexus.lab.test.crt" \
  --resolve nexus.lab.test:8443:127.0.0.1 \
  https://nexus.lab.test:8443/service/rest/v1/status

The socket, server, and certificate file were unchanged; only the requested hostname changed. That isolates certificate identity as the cause.

6. Docker/OCI client trusts an endpoint identity, not “the Nexus server”

Container clients key login and trust behavior to the registry endpoint they actually use. Changing from a connector such as nexus.example.invalid:18443 to a path-routed endpoint such as repo.example.invalid/repository-name/image changes the client-facing authority and often the authentication challenge path. A certificate trusted for one hostname/port does not automatically prove the other endpoint is configured correctly.

Current OCI docs also distinguish self-hosted HTTP behavior: Docker requires an insecure-registry configuration for plain HTTP, while Helm/ORAS can use explicit plain-HTTP options. Production guidance should converge on valid HTTPS instead of expanding insecure-registry exceptions.

7. Context-path mismatch: 404 is often a routing error, not missing content

Before changing a repository URL, check the application context. Sonatype’s runtime documentation makes the context path a Nexus runtime property.

8. Admin port accidentally internet-exposed

The most severe network mistake is often not a 5xx response—it is a successful direct connection to the backend. Test reachability from the intended client network and from the proxy host separately. A single-host lab expects 127.0.0.1:8081; a multi-host production design expects a private address/firewall rule reachable only from the edge or trusted administration plane.

# Local server evidence
ss -ltnp 2>/dev/null | grep ':8081' || netstat -an | grep '8081'

# Production runbook test (execute only from approved test hosts):
# client network -> backend:8081 MUST fail
# reverse proxy -> backend:8081 MUST succeed
# client network -> edge:443 MUST follow the intended policy

9. 401, 403, 404, TLS failure, and connection failure are different families

10. Performance diagnosis by causal layer

TLS handshake time, reverse-proxy buffering, client cache, Nexus proxy cache, upstream latency, database latency, blob IO, JVM memory, task load, and network packet loss can all produce “slow downloads,” but they require different evidence. Measure time-to-first-byte and total transfer at the edge, compare with direct private-backend tests from the proxy host, then inspect Nexus metrics/logs only when the edge-to-backend path is proven.

Do not disable TLS verification or expose 8081 publicly to obtain a “faster baseline.” A valid benchmark respects the intended security architecture.

11. Security-sensitive corrections

• Certificate/key rotation: validate SAN, chain, key permissions, and rollback before replacing the active edge certificate.
• Forwarded headers: accept them only from trusted proxy paths; do not expose a header-authenticated backend directly.
• Context path/listener changes: perform only on a disposable/test instance first because they require restart and can invalidate every client URL.
• Firewall changes: use narrowly scoped source/destination/port rules and independent reachability tests.
• Credentials: never put Basic auth, tokens, private keys, or Authorization headers into evidence logs.

12. Knowledge check

13. Summary and next step

Network diagnostics should identify the failing hop before changing state. The checkpoint now combines that method into a production-shaped proof: HTTPS-only edge behavior, exact hostname verification, secure publication, hash equality, direct-backend boundary, and a documented firewall model.

Official references and version notes

• Sonatype: Run Behind a Reverse Proxy — forwarded headers, proxy patterns, SSL termination.
• Sonatype: Configuring SSL — direct HTTPS and certificate troubleshooting boundaries.
• Sonatype: Configure OCI Repository — current OCI routing and TLS/client behavior.
• Sonatype: 3.83 Release Notes — forwarded-host fixes illustrate why proxy behavior is version-sensitive.