Monitor proxy health with n8n

Define what a healthy check means

A successful request to one endpoint establishes that the proxy carried that request at that time. It does not prove that every destination works or that a country database agrees with the selected location.

Use a controlled, lightweight endpoint for recurring checks. Record the HTTP result and time, and use a separate exit-IP observation when location is part of the requirement. A rejected destination should not automatically be labeled a dead proxy.

Import the check workflow

The download uses a Manual Trigger, an HTTP Request node and a result-classification step. Begin manually, confirm the behavior and only then attach your own schedule and notification destination. This avoids creating unattended traffic or sending messages before you have configured the workflow.

The proxy URL is read from an environment variable on a self-hosted n8n instance. Environment access may be disabled by your n8n configuration. Keep that restriction unless the instance administrator has approved the specific workflow and secret-access method. On hosted instances, use the supported secret-management configuration instead of assuming local environment variables are available.

Configure the proxy and destination separately

n8n's HTTP Request Proxy option describes the proxy used for the request. Destination authentication is a separate concern. An arbitrary header credential does not configure proxy authentication.

Use an HTTP proxy URL with the endpoint and authentication supplied for your plan. Set a bounded timeout and keep TLS verification enabled. For the first run, use a controlled endpoint that returns a predictable response. The downloadable workflow expects MP_PROXY_URL and MP_HEALTH_URL to be supplied by the instance configuration.

HTTP Request → URL:
{{ $env.MP_HEALTH_URL }}

HTTP Request → Options → Proxy:
{{ $env.MP_PROXY_URL }}

HTTP Request → Options → Timeout:
15000

Add incident state before adding alerts

One failed check should create an observation, not an alert storm. Store the previous state in your approved database or n8n data store. Confirm a failure across successive checks, then send a single incident notification. Send one recovery notification after the check succeeds again.

The provided check does not claim to implement persistent incident storage or a universal availability percentage. Add those pieces to match your operating requirements. Define which observations count toward availability, how maintenance is handled and how missing check results are treated.

1. Validate a successful manual check.
2. Use the local fixture to test invalid authentication and a failed destination.
3. Decide which fields may be retained and remove sensitive URLs from errors.
4. Connect a persistent incident state store.
5. Add a modest schedule and deduplicated notifications to an authorized destination.
6. Verify recovery and a missing-check condition, not only failure.