A KernelCare communication error can prevent patch retrieval while the website remains accessible. Diagnosis depends on the delivery path: direct access to TuxCare services, a proxy or an internal ePortal. A rule limited to one server’s port 80 does not describe these configurations.
These checks are for the responsible administrator. For a Nuagerie-managed service, report the error before changing DNS resolvers, firewall settings or license registration.
Identify the destinations actually used
The KernelCare documentation identifies these roles in a typical direct configuration:
cln.cloudlinux.comfor registration and licensing exchanges;patches.kernelcare.comfor patches;repo.cloudlinux.comfor agent installation or update packages.
With ePortal, clients can use the configured internal address while ePortal accesses its own sources. The ePortal documentation describes downloads.kernelcare.com, repositories and conditional destinations. Custom URLs and enabled features must also be considered.
These examples are not a complete firewall ruleset. HTTPS normally uses TCP 443, but proxy and internal service addresses and ports depend on your configuration. Operating-system repositories and other dependencies can introduce separate requirements. Do not expose inbound administration access to the Internet to resolve an outbound download failure.
Check each stage of the network path
- DNS: confirm that the agent’s environment resolves the intended destination. A private ePortal hostname needs the appropriate internal DNS path. Our hostname-resolution troubleshooting guide distinguishes DNS failures from other network errors.
- Connection: examine routing, outbound filtering and proxy access from the affected server. A successful test from a workstation does not validate that path.
- TLS: check the presented name, certificate validity, trust chain and system clock. If HTTPS inspection is involved, have its owner validate the configuration. Do not disable certificate verification.
- Proxy: compare the configuration used by automated execution with the interactive terminal. A proxy set in a shell session may be missing from a scheduled task. Keep its credentials confidential.
- Redirects: identify repository downloads’ final destinations. TuxCare documents redirects to mirrors and CDNs; fixed IP addresses or an incomplete hostname list can block downloads. Have the network policy adjusted to the validated scope, without unrestricted access.
Separate connectivity, authorization and application
A timeout, TLS error and HTTP 401 or 403 rejection require different investigations. A rejection may originate from the service or an intermediary. Identify the exact stage and destination, then have permissions and licensing checked without repeatedly removing or registering the license.
TuxCare describes a download rejection despite a license being reported as valid. Conversely, receiving metadata does not prove that the patch payload was obtained and applied. Check the outcome for the affected kernel and the last successful run.
Provide useful support information
Record the time, failing stage, message, agent and operating-system versions, and whether a proxy or ePortal is involved. Remove keys, passwords and private data before attaching relevant excerpts to a request in your Client Area. Do not automatically run a tool that uploads a diagnostic report to the vendor.
For a network without direct access, see our guide to KernelCare and ePortal in isolated environments. For external infrastructure, contact Nuagerie to establish the diagnostic scope and responsibilities.
