Frequently Asked Questions

Session management

Why does the user session get lost during or after authentication?

When using cookie-based identification with the dynamic session management, for security reasons nevisProxy regenerates the cookie after a successful authentication. In certain contexts (parallel AJAX requests), the new cookie may get lost if there are parallel requests with the old cookie before the new cookie could reach the client, which means the session may get lost on the user side.

To prevent this, the best solution is to prohibit parallel requests during the authentication phase on the client side, so the new cookie is registered properly, and follow-up requests use the valid cookie.

Another workaround can be setting the Cookie.OnInvalid parameter of the SessionManagementFilter to status code 409 (Conflict), which signals the client to reject the response and retry — parallel requests using the old cookie should then succeed on retry with the new cookie.

The parameter Cookie.KeepOldCookieTimeout can also help in this use-case. It configures the number of seconds that an existing cookie is valid after a new one is renegotiated. Increasing the value can help minimize the chance of session loss during a login or step-up with parallel request.

Finally, the cookie regeneration can be disabled with the RenewIdentification parameter of the IdentityCreationFilter, but this is not recommended due to security concerns.

Why do sessions get lost when multiple nevisProxy instances share a remote session store?

All nevisProxy instances that share the same remote session store (MySQL or PostgreSQL) must be configured with the same set of web.xml files. If instances use different web.xml files, a session created by one instance may not be found by another, causing session loss.

If two proxy instances serve different sets of applications, give each its own session store rather than sharing one.

When using nevisAdmin 4, make sure all instances sharing the same session store use the same Managed Remote Session Store pattern.

How does nevisProxy protect against login CSRF and session fixation?

The RenewIdentification parameter of the IdentityCreationFilter (enabled by default) regenerates the session cookie after a successful authentication. This prevents session fixation attacks, where an attacker tricks a user into authenticating on a pre-set session ID.

For general CSRF protection of the whole site including the login pages, configure the CSRFFilter on the appropriate URL paths.

Disabling RenewIdentification is not recommended. If session loss during parallel login requests is the concern, see the question about session loss during authentication instead.

Why does nevisProxy exhaust MariaDB's max_prepared_stmt_count?

Each nevisProxy instance uses a fixed pool of prepared statements per database connection. The required value can be calculated as:

max_prepared_stmt_count = <instances> × <connections_per_instance> × 22

Increase max_prepared_stmt_count in MariaDB accordingly, for example with SET GLOBAL max_prepared_stmt_count=50000. The main trade-off is increased MariaDB memory usage.

After upgrading the session store to MariaDB 10.6, a small percentage of requests hang for ~50 seconds. What is the fix?

Set the RetriesOnLockWaitTimeOut bc property on the MySQLSessionStoreServlet to 3 or higher:

ch.nevis.bc.sql.mysql.RetriesOnLockWaitTimeOut=3

This instructs nevisProxy to retry transactions that receive a lock-wait timeout rather than failing the request. The underlying deadlock condition in MariaDB 10.6 was also addressed in NEVISPROXY-7431 (nevisProxy 8.2505.3), which adds error code 2014 to the default ConnectionErrorCodes.

Two nevisProxy instances are each connected to a different primary in a master-master MariaDB setup and sessions are getting out of sync. What is the correct architecture?

Both nevisProxy instances must connect to the same primary database node. The second MariaDB node should act as a read replica only. When each proxy writes to a different primary, concurrent writes create replication conflicts and lock contention. Reconfiguring both proxies to share a single primary resolves the issue.

Why does the remote session store log foreign key errors at startup?

nevisProxy validates the database schema of the remote session store on startup. If a foreign key is missing or mismatched, a CACH-0069 error similar to the following is logged:

3-ERROR : CacheTableChecker_1_0::checkForeignKey: The foreign key 'FOREIGN KEY(ID) REFERENCES session' ...

This error usually indicates a schema mismatch between the database nodes. The servlet will still initialize and operate. To investigate, increase the log level for the session store servlet (BC.Tracer.DebugProfile.NPMySQLSessSrv=4) and verify the schema is identical on all nodes:

SELECT * FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE a
  JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS b USING (CONSTRAINT_NAME)\G

After upgrading MariaDB to a new major version (for example, from 10.3 to 10.6), ensure the session store schema migration steps from the nevisProxy release notes have been applied.

Frontend and backend connectivity

How to solve frontend connection issues?

The most frequent issue on the frontend side is when a request gets blocked but there is no corresponding log entry in navajo.log. This can happen when the request fails on the Apache level, before reaching the Navajo module, due to some limitation or restriction; for example, it has too many request headers. To debug the issue, check the Apache log, which should have a proper error message describing the exact error. You may need to increase the Apache log level by setting the LogLevel attribute in navajo.xml. Possible causes include:

• The mod_qos directives are too strict.
• The various LimitRequest* directives are too strict.
• Client certificate is required but the client did not provide one.
• Make sure the MaxClientsPerIpAddr configuration is not used as it may lead to cores.
• Verify the server certificates are correct using openssl verify.
• Verify the server is reachable using openssl s_client.

If even the Apache log does not have any entry about the failed request, it means it failed before reaching nevisProxy, and the error comes from a previous network element (e.g. firewall, load balancer).

How to solve backend connection issues?

If nevisProxy runs into a backend connection issue, usually an error is logged in navajo.log. If that is not descriptive enough, it is worth increasing the log level of the servlet experiencing the connection issues and checking the traced error code in the appendix for details and hints. Other possible steps can be:

• Check the health of the backend.
• Check that during the nevisProxy startup, there is no error traced in the initialization step.
• Verify that if a hostname is used instead of IP address, the name can be resolved. Hostname resolution happens at servlet initialization (startup); if it fails, the backend is marked unavailable. Use an IP address or /etc/hosts for internal hostnames that may not be available via DNS.
• Verify that the backend is reachable from the nevisProxy host. Example command: openssl s_client -connect <hostname>:<port> -showcerts [-CAfile ca.pem -verify_hostname <hostname>]
• Verify that the used certificates are correct and valid if TLS is enabled. Example command: openssl verify -verbose -CAfile ca.pem certificate.pem
• Check that if the backend sends a valid and complete HTTP response message. Consider using network tools such as Wireshark or tcpdump for this.
• If you are connecting to a backend with multiple virtual hosts, make sure SNI is enabled.

Does nevisProxy support Server-Sent Events (SSE) and long polling?

Yes, nevisProxy supports both SSE and long polling. Because both technologies rely on long-lasting open connections, the configured connection limits can become a bottleneck under high load. If you encounter issues, review the MaxClients parameter in navajo.xml and the MaxConnections parameter of the relevant connector servlet.

How do I configure active backend health checks?

The LoadBalancerServlet supports active health checking via the IsAliveURI.EnablePing parameter. When enabled, nevisProxy periodically sends a request to a configured URI on each backend to determine its availability. The parameter IsAliveURI.EnablePing.OnlyInspectPingResponseCode lets you control whether only the HTTP status code is evaluated.

For the HttpConnectorServlet, nevisProxy marks a backend as unavailable when a connection attempt fails, and retries after the ResourceManager.RetryTimeout interval.

How do I debug WebSocket connection issues?

If WebSocket frames stop or behave unexpectedly, first check whether the issue reproduces with all filters removed from in front of the WebSocketServlet. This isolates whether a filter is interfering. Re-add filters one at a time to identify the culprit.

Also verify that long-lasting WebSocket connections are not closed due to a session timeout. Make sure UpdateSessionInterval in the WebSocketServlet is configured to keep the session alive for the duration of the connection.

Why does the RewriteFilter not rewrite response bodies?

Two requirements must both be met for the RewriteFilter to process a response body:

1. Content-Type match — the response Content-Type must appear in the filter's ResponseBody.ContentTypes parameter. Common types like text/html are included by default, but others (e.g. application/json) must be added explicitly.
2. Uncompressed response — the RewriteFilter skips compressed response bodies and logs [BASE-0037] Unsupported Content-Encoding. The body may not be rewritten. Add an InflateFilter to the chain to decompress first. The InflateFilter supports gzip, deflate, and Brotli.

Because response-phase processing traverses the filter chain in reverse order compared to the request phase, the InflateFilter must be mapped after the RewriteFilter in web.xml to execute before it on the response.

How do I route backend connections through an outbound forward proxy?

Use the ForwardProxy parameter of the BackendConnectorServlet to route HTTPS backend connections through a forward proxy. Set ForwardProxy to the proxy address in host:port format. If the forward proxy requires authentication, configure ForwardProxy.UserName and ForwardProxy.Password.

Does nevisProxy support HTTP/2 for backend connections?

No. All backend connections from nevisProxy to application servers use HTTP/1.1. HTTP/2 is supported on the frontend (client-to-proxy) side only. The Http2Servlet is specifically for gRPC, not for generic HTTP/2 backend proxying.

Can nevisProxy and nevisAuth run on different LTS versions at the same time?

No. Running mismatched LTS versions between nevisProxy and nevisAuth is not supported or tested. The communication protocol between the two components can differ between LTS releases, which may cause unexpected runtime errors. Both components should be on the same LTS version.

Why is nevisproxy_httpd.conf not regenerated after a nevisAdmin 4 deployment?

Two common causes:

1. The generateCarrierConfig="false" attribute is set on the <Service> element in navajo.xml, which disables Apache config file generation entirely.
2. A "Generic nevisProxy Instance Settings" pattern is attached under Advanced Settings → Additional Settings on the instance, and its content overrides the relevant navajo.xml directives.

Check both when the generated Apache configuration does not reflect the expected changes.

TLS and SSL

Why does client certificate authentication (mTLS) not work with TLS 1.3 or HTTP/2?

Client certificate authentication is not compatible with TLS 1.3 or HTTP/2 frontend connections by design:

• TLS 1.3 removed the renegotiation mechanism that TLS 1.2 relied on for in-connection client certificate requests. The replacement mechanism (post-handshake authentication) is not implemented by most browsers and TLS clients.
• HTTP/2 does not support TLS renegotiation. Experimental support for client certificate authentication with HTTP/2 is available.

If mTLS is required, configure the affected frontend connections to use TLS 1.2 and HTTP/1.1.

Why does mTLS fail with "unable to get issuer certificate locally" (error 20)?

OpenSSL error 20 (X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY) means the issuer certificate of the presented certificate could not be found in the configured trust store. The most common cause in a nevisProxy ↔ nevisAuth mTLS setup is that the intermediate CA certificate is missing from one of the trust stores.

Check that the trust stores on both nevisProxy and nevisAuth contain all intermediate CA certificates in the chain, not only the root CA.

Use openssl s_client to reproduce and diagnose the handshake before adjusting the proxy configuration:

openssl s_client -connect <host>:<port> -CAfile ca-chain.pem -showcerts

What is the risk of using ClientCert=optional_no_ca in the IdentityCreationFilter?

The value optional_no_ca instructs nevisProxy to skip all CA-based validation of the client certificate. A certificate that has been modified or is not signed by a trusted CA will still be accepted, because nothing in the chain is verified.

Always use optional instead, which validates the certificate against a configured CA trust store. Setting optional_no_ca effectively disables certificate authentication as a security control.

How do I support private-use URI schemes for OAuth2 native apps?

Native mobile apps (as defined in RFC 8252) sometimes use custom URI schemes for OAuth2 redirect URIs, for example com.example.app:/oauth2redirect. nevisProxy's IdentityCreationFilter normally interprets a single-slash URI as a relative path and rewrites it, breaking the redirect.

To prevent the IdentityCreationFilter from rewriting private-use URI schemes, set the following parameters:

• PrivateUriSchemeRegex — set to true to enable regex-based matching.
• PrivateUriSchemeRegex.Pattern — a regex matching the private URI schemes to exclude from rewriting. The default pattern already covers schemes conforming to the RFC 8252 specification.

For rewrites done by the HttpConnectorServlet, configure the AutoRewrite parameter to exclude the relevant URI schemes.

Why do client certificates with fractional seconds in validity dates fail?

OpenSSL 1.1.1 introduced strict RFC 5280 compliance, which no longer permits fractional seconds or timezone offsets in certificate validity dates (notBefore / notAfter). A client certificate with a timestamp like Mar 8 13:14:27.718 2010 GMT will be rejected.

The only remediation is to reissue the affected certificates without millisecond precision in the validity fields. There is no configuration option in nevisProxy or OpenSSL to disable this check.

Is disabling SSLCheckPeerHostname for the nevisProxy–nevisAuth connection a security risk?

Not significantly, provided that mutual TLS (two-way TLS with a private CA) is already in place. SSLCheckPeerHostname adds hostname verification on top of the existing certificate validation. In a properly configured mTLS setup, a man-in-the-middle attack is already prevented by certificate trust — hostname verification is an extra layer. Enabling the parameter is still recommended for defense in depth; it became configurable via the nevisAdmin 4 Authentication Realm pattern in the May 2022 release.

WAF and ModSecurity

Should the ModSecurity native audit log be used in production?

No. The ModSecurity audit log is not managed by nevisProxy and can cause disk space issues (the log may grow without bound). We recommend not relying on the ModSecurity native audit log in production environments.

For request logging and security auditing, use the nevisProxy LoggerFilter instead, which is integrated with the standard nevisProxy log-rotation infrastructure.

Has nevisProxy been tested with OWASP ModSecurity Core Rule Set (CRS) 4.x?

Yes. nevisProxy has been tested with CRS 4.x. nevisAdmin 4 lets you select from several supported CRS versions including 4.x. If you manage your configuration manually without nevisAdmin 4, you must include the CRS yourself. Nevis supports the basic integration configuration; custom rule tuning is outside product support scope.

Does enabling ModSecurity significantly increase CPU usage?

Yes, a significant CPU increase is expected and normal. ModSecurity evaluates every request against all active rules, which is inherently CPU-intensive. The overhead depends on the number and complexity of rules and the request rate. This cost is unavoidable — it is the trade-off for running a full Web Application Firewall.

ModSecurity response-body rules cause a SecurityException and session loss. How do I fix this?

When a response-body rule fires after the response headers have already been sent to the client (response committed), nevisProxy cannot send an error response, so it throws a SecurityException which invalidates the session. This also affects backends that use Transfer-Encoding: chunked, where chunks may be partially committed before the rule triggers.

Set the NEEDS_BUFFERED_BODY request flag in the relevant filter mapping. This makes nevisProxy buffer the complete response body before forwarding any data to the client, so ModSecurity can evaluate response-body rules against the full content safely.

The SoapFilter needs to make outbound HTTP calls when loading XML schemas. Can this be enabled?

Yes. The LoadExternalEntity parameter of the SoapFilter controls this behavior. It defaults to false, which prevents the filter from making outbound calls to resolve external XML entities or schemas, and closes the XML External Entity (XXE) injection attack surface. Set it to true only if your configuration genuinely requires fetching remote schemas.

Does mod_qos provide full DDoS protection when HTTP/2 is enabled on the frontend?

Partially. mod_qos is designed for HTTP/1.0 and HTTP/1.1. When HTTP/2 is enabled, only request-level control directives work as expected. Connection-level rate-limiting directives do not apply to HTTP/2 connections. If comprehensive DDoS protection is needed for HTTP/2 traffic, consider adding controls at the load balancer or network layer.

Is nevisProxy affected by JSON-based SQL injection WAF evasion techniques?

nevisProxy includes the OWASP Core Rule Set (CRS) via ModSecurity. The basic CRS configuration (paranoia level 1) does not block all variants of JSON-based SQL injection evasion. CRS paranoia level 2 provides broader coverage and is recommended if your applications process JSON input that could be forwarded to a SQL backend. Monitor the CRS project for rule updates addressing specific techniques.

Can a high MaxNestingDepth in the JsonFilter cause worker crashes?

Yes. Parsing deeply nested JSON consumes memory proportional to the nesting depth. If MaxNestingDepth is set very high and a request with extreme nesting arrives, the worker process can exhaust its memory and crash. There is no internal safeguard — even writing the error log requires memory at that point.

Keep MaxNestingDepth at a conservative value and validate the limit under load testing before deploying to production. ModSecurity with the OWASP CRS provides a complementary protection layer against deep-nesting injection attempts.

Are CVEs affecting mod_lua relevant to nevisProxy?

No. nevisProxy uses its own Lua integration built into the Navajo container and does not load Apache's mod_lua module. CVEs specific to mod_lua (for example, CVE-2021-44790) do not affect nevisProxy's Lua functionality. You can verify that mod_lua is not loaded by checking that there is no LoadModule mod_lua directive in the generated Apache configuration.

More broadly, most Lua-related CVEs describe a scenario where an attacker can supply or execute their own Lua script. In nevisProxy, Lua scripts are part of the proxy configuration (web.xml) and can only be modified by a system administrator or integrator with access to the configuration files. An attacker who can already modify the proxy configuration has full system access, making the Lua vector moot. This reasoning applies when assessing other Lua CVEs against nevisProxy as well.

Performance

Under high load, nevisProxy response times increase while backend times remain fast. What should be checked?

Two configuration points are often responsible:

• KeepAlive.ConnectionPoolSize on backend connector servlets — if the pool is too small, incoming requests queue waiting for a free connection slot. Increase this value to match the expected peak concurrency.
• DNSCache.ttl on connector servlets — if DNS caching is not configured (or TTL is 0), every request triggers a DNS lookup. Set a non-zero TTL (the default is 3600 seconds) to avoid this overhead.

If NPPerfMeter traces show no slow filter or servlet, the bottleneck is likely at the frontend network I/O level (file descriptor limits, kernel context switches) rather than within nevisProxy itself.

What is the recommended maximum number of backends per nevisProxy instance?

As a guideline, a single nevisProxy instance should not be configured with more than 10–20 backend servlets. Exceeding this limit can lead to significantly longer startup times and increased resource usage. If you need to proxy a large number of backends, consider distributing them across multiple nevisProxy instances.

How do I serve pre-compressed static content efficiently?

Map a CacheFilter between the frontend connector and the DeflateFilter, restricted to the URL patterns of your static files. The CacheFilter stores the response after the first request, so subsequent requests are served from cache without re-compressing.

The DeflateFilter supports Brotli compression in addition to gzip and deflate, which allows serving pre-compressed content in all commonly supported formats.

Filters and servlets

nevisProxy returns a raw Apache error page (APAC-0005) instead of a custom error page for invalid requests. How do I serve a custom page?

APAC-0005 means the error was raised by Apache httpd before (or outside) the Navajo filter chain. Two approaches are needed:

1. Configure an ErrorFilter in web.xml with a StatusCode mapping (e.g. 400 → a custom error servlet or file) for errors the filter chain catches.
2. For errors that occur before the filter chain (e.g. a malformed request line), add an Apache ErrorDocument directive for the relevant status code via the ApacheConfigFilter.

How do I send a different error response depending on the response Content-Type?

Use the ErrorFilter with a Condition on the response Content-Type. The StatusCode parameter accepts Condition:ENV:bcx.servlet.response.Header.Content-Type expressions, so you can map different status codes to different error responses based on the content type — all within a single ErrorFilter, without needing separate filter chains.

Note that the FilterMappingFilter selects its chain at request time and cannot branch on response attributes, so it cannot be used for this purpose.

Can nevisProxy respond directly to HTTP OPTIONS requests (CORS pre-flight) without forwarding them to the backend?

Not natively. Use a LuaFilter that checks whether the request method is OPTIONS, sets the required CORS response headers, and calls resp:send(204) to return a 204 No Content response without forwarding to the backend.

Why does the EncryptionFilter not encrypt URL fragments?

URL fragments (the #… part of a URL) are anchor references that are never sent to the server by the browser, so the EncryptionFilter skips them by default. If your application embeds URI-like content inside a fragment that needs to be encrypted, use the SubstringUrlPatterns parameter to define a regex that extracts those URIs from within the fragment for encryption.

Kubernetes

How should nevisProxy handle worker crashes in Kubernetes?

By default, when a worker crashes nevisProxy enters a recovery phase and returns HTTP 503 for up to two minutes before resuming normal operation. In Kubernetes this prolonged unavailability can be avoided by setting the crashRecoveryStrategy attribute to kill in the <Service> element of navajo.xml:

<Service ... crashRecoveryStrategy="kill">

With this setting nevisProxy exits immediately when a worker crashes, so the Kubernetes liveness probe detects the failure and restarts the pod cleanly. This also eliminates the risk of serving requests from a corrupted database client state after an in-process recovery.

Logging and tracing

How do trace levels work in nevisProxy?

In nevisProxy, the verbosity of the logs depends on two things:

• The base threshold set by BC.Tracer.ThresholdBase.
• The individual LogLevels set by the filters/servlets.

For example, if we set BC.Tracer.ThresholdBase=5, and set the LogLevel of the filters/servlets to 0, the logs contain all messages with a severity level of 0-5. If we take the previous ThresholdBase, and set for example, BC.Tracer.DebugProfile.IW4IdentCreaFlt=4, beside the already logged messages with severity 0-5, nevisProxy traces all log messages for the IdentityCreationFilter with a severity level of 6-9. This happens because the ThresholdBase is set to 5 and the individual LogLevel of 4 set for the filter results in a LogLevel of 9 (= 5 + 4) for the IdentityCreationFilter.

The mapping between the LogLevels and severity is shown in the following table:

Level	Severity	Description
0	EMERGENCY	Nothing works anymore.
1	ALERT	Something should be corrected immediately.
2	CRITICAL	A critical situation has occurred.
3	ERROR	Other error messages.
5	NOTICE	Things you should know.
6	INFO	Things of interest.
7	DEBUG_LOW	Low debug level.
8	DEBUG_MED	Medium debug level.
9	DEBUG_HIGH	High debug level (enter/leave).
10	DEBUG_MAX	Highest debug level.

Frequently used trace groups for debugging

To make debugging and opening support tickets more efficient, here are a few relevant trace groups, you should consider raising or enabling before reproducing an issue, and sending the logs to the nevisProxy team:

General trace groups

BC.Tracer.DebugProfile.NavajoOp=4
BC.Tracer.DebugProfile.IsiwebOp=4

Trace groups regarding backend connectivity

BC.Tracer.DebugProfile.IW4WebSocketSrv=4
BC.Tracer.DebugProfile.IW4HttpConnSrv=4
BC.Tracer.DebugProfile.IW4HttpsConnSrv=4
BC.Tracer.DebugProfile.NPBackendSrv=4

Frontend connection

BC.Tracer.DebugProfile.NavajoRequest=4

Trace groups relevant to the authentication process

BC.Tracer.DebugProfile.IW4IdentCreaFlt=4
BC.Tracer.DebugProfile.IW4Esau4ConnSrv=4
BC.Tracer.DebugProfile.IW4SecRoleFlt=4

SSL/TLS-related trace groups

For frontend connections

BC.Tracer.DebugProfile.NavajoSSL=4
BC.Tracer.DebugProfile.Apache=4

Also set the property LogLevel in the file navajo.xml, as follows:

LogLevel="debug ssl:trace5"

For backend connections

BC.Tracer.DebugProfile.OpenSSLHandshk=4
BC.Tracer.DebugProfile.OpenSSLRecord=4
BC.Tracer.DebugProfile.OpenSSLStream=4
bcx.net.debug.host=all
bcx.net.debug=handshake,record,ssl, ssl-key

Configuring logging in nevisAdmin 4

In nevisAdmin 4, you can use the pattern nevisProxy Log Settings to configure the severity of the logs. The LogLevel, which is the ThresholdBase, is set to NOTICE by default. This can be overridden on a filter/servlet basis, by defining a value for the filter/servlet under the LogLevel Overrides.

In some cases, nevisAdmin 4 uses a different name than nevisProxy for the different severity levels.

Severity Level	nevisProxy	nevisAdmin4
3	ERROR	ERROR
5	NOTICE	NOTICE
6	INFO	INFO
7	DEBUG_LOW	DEBUG
9	DEBUG_HIGH	DEBUG_HIGH
10	DEBUG_MAX	TRACE

Use only the suffix of the name of the described trace group combined with the LogLevel as string. Do not use the numbers of the Reference Guide, as nevisAdmin 4 calculates the numbers automatically.

Getting support

General issues

• First try to isolate, and reproduce the issue locally.
• Enable the relevant trace groups, with the correct trace levels.
• From the collected logs, identify, and mark out the issue.
• Contact Nevis support with the collected navajo.log, steps to reproduce the issue, and the necessary configuration files: web.xml and navajo.xml for the reproduction.

Connectivity issues

• Check the FAQ on connectivity issues.
• If the issue persists, enable the relevant trace groups, and try to reproduce the issue.
• Contact support with the collected navajo.log and apache.log, steps to reproduce the issue, and necessary configuration files: web.xml and navajo.xml.

HSM-related issues

• Try to isolate, and reproduce the issue locally.
• Get in touch with your HSM support vendor to verify the issue is not related to their libraries/engines, HSM configuration, or both.
• Try to replicate the issue with a plain Apache httpd server, setting numservers=1 and serverlimit=1.
• If all the above do not lead to a solution, and the HSM works as expected with a plain Apache, then follow the steps described in the general issues part of the FAQ.

Memory related issues

If the host runs out of memory after some days there may be a memory leak in one of the nevisproxy components. We regularly run memory leak tests on our own components but we can't exclude any leak on external software.

The following third-party libraries had some memory leak issues in the past:

• mariadb-connector-c version 3.1.10 or older