Skip to main content

​
Overview

When you create a resource in Pangolin, you define different targets that specify where traffic should be routed within your network. Each target represents a specific destination that the resource can proxy to when handling incoming requests.
Targets are created on the Newt tunnel, enabling traffic to reach destinations on the remote network without requiring additional routing configuration.

​
How Targets Work

​
Target Routing

Targets function as destination endpoints for your resources:
  1. Resource Creation: When you create a resource, you configure one or more targets
  2. Traffic Routing: Incoming traffic is routed to the appropriate target based on your configuration
  3. Network Access: Newt proxy routes traffic to the local network through the tunnel
  4. Direct Connection: No additional routing is necessary on the remote network

​
Multi-Site Targets (v1.9.0+)

With the introduction of update 1.9.0, targets now have sites associated with them. This enhancement provides significant benefits for reliability and load distribution.

​
Site-Distributed Resources

You can now configure targets across different sites for the same resource:

High Availability

Distribute your resources across multiple sites so that if one site goes down, traffic automatically continues to be served from other available sites.

Load Balancing

Set up load balancing across sites to distribute traffic in a round-robin fashion between all available targets.

​
Load Balancing Requirements

Load balancing between different targets only works when sites are connected to the same node. In Pangolin instances with multiple remote nodes, ensure load balancing occurs on the same node.
To ensure effective load balancing in multi-node environments: 
newt --prefer-endpoint <specific-endpoint> <other-args>
Pangolin currently does not load balance between nodes, only between targets on the same node.

​
Path-Based Routing

Path-based routing allows you to direct traffic to different targets based on the request path. This enables sophisticated routing scenarios where different services can handle different parts of your application.

​
How Path-Based Routing Works

Each target can be configured with optional path routing parameters:
  • Path: The path pattern to match against incoming requests
  • Match: The matching strategy to use when comparing the request path
When a request comes in, Pangolin evaluates the path against all targets and routes traffic to the target with the matching path configuration.

​
Match Types

Pangolin supports three different matching strategies:

Exact Match

exact: The request path must match the configured path exactly.Example: Path /api/users with exact match only matches /api/users

Prefix Match

prefix: The request path must start with the configured path.Example: Path /api with prefix match matches /api/users, /api/orders, /api/users/123, etc.

Regex Match

regex: The request path is matched against a regular expression pattern.Example: Path ^/api/users/[0-9]+$ with regex match matches /api/users/123 but not /api/users/abc
Targets example

Pangolin UI showing targets with path-based routing configuration

​
Load Balancing with Path-Based Routing

When multiple targets have the same path and match configuration, Pangolin will load balance between them using round-robin distribution. Example Scenario:
  • Target 1: Path /api, Match prefix, Address 10.0.1.10:8080
  • Target 2: Path /api, Match prefix, Address 10.0.1.11:8080
  • Target 3: Path /web, Match prefix, Address 10.0.1.12:80
In this configuration:
  • Requests to /api/users will be load balanced between Target 1 and Target 2
  • Requests to /web/dashboard will only go to Target 3

​
Path Rewriting

Path rewriting allows you to modify the request path before it reaches your backend service. This enables you to expose different URL structures to your users while maintaining your existing backend API paths.
Path rewriting requires path-based routing to be configured first. You must set up a Path Match before you can configure path rewriting.

​
How Path Rewriting Works

After Pangolin matches a request using path-based routing, it can rewrite the path before forwarding the request to your target service. Each target with path matching configured can optionally include path rewriting:
  • Rewrite Type: The strategy to use for rewriting the path
  • Rewrite Value: The new path or pattern to apply (optional for Strip Prefix)
The rewriting happens after the path match evaluation but before the request reaches your backend service.

​
Rewrite Types

Pangolin supports four different rewriting strategies:

Prefix Rewrite

prefix: Replaces the matched portion with a new prefix, preserving the rest of the path.
  • With Prefix Match: /api → /v2/api transforms /api/users into /v2/api/users
  • With Exact Match: /old → /new transforms /old into /new
  • With Regex Match: Uses the regex pattern with the rewrite value as replacement

Exact Rewrite

exact: Replaces the matched path with the exact rewrite path.Example: Match path /api/users → Rewrite to /users transforms /api/users into /users

Regex Rewrite

regex: Uses regular expression substitution to transform the path. Works with any match type.
  • With Regex Match: Uses the regex pattern directly
  • With Prefix Match: Automatically captures everything after the prefix with (.*)
  • With Exact Match: Matches the exact path
Example: Match path ^/api/v1/(.*) (regex) → Rewrite to /api/v2/$1 transforms /api/v1/users into /api/v2/users

Strip Prefix

stripPrefix: Removes the matched prefix from the path.
  • With Prefix Match: Efficiently strips the prefix using Traefik’s stripPrefix middleware
  • With Exact/Regex Match: Uses regex replacement to remove the matched portion
  • Optionally add a new prefix after stripping by providing a rewrite value
Example: Match path /api (prefix) → Strip Prefix transforms /api/users into /usersExample with new prefix: Match path /old (prefix) → Strip Prefix + Rewrite to /new transforms /old/users into /new/users
Targets with path rewriting

Pangolin UI showing path rewriting configuration

​
Configuration Requirements

Path rewriting validation ensures your configuration is valid:
  • Path rewriting requires path matching to be configured first
  • When using rewrite types other than Strip Prefix, both rewrite path and rewrite type must be specified together
  • For regex path matching, the path pattern must be a valid regular expression
  • Strip Prefix works with any match type, but is most effective with Prefix match type

​
Automatic Path Normalization

Pangolin automatically normalizes paths to ensure correct routing:
  • Non-regex paths that don’t start with / will have / prepended automatically
  • Non-regex rewrite paths that don’t start with / will have / prepended automatically
  • This ensures consistent behavior across different configurations

​
Load Balancing with Path Rewriting

All targets with identical path match and path rewrite configurations will be load balanced together. Example:
  • Target 1: Match /api (prefix), Rewrite /v2 (prefix), Address 10.0.1.10:8080
  • Target 2: Match /api (prefix), Rewrite /v2 (prefix), Address 10.0.1.11:8080
  • Target 3: Match /api (prefix), Strip Prefix, Address 10.0.1.12:8080
Requests to /api/users will:
  • Load balance between Target 1 and Target 2 (both rewrite to /v2/users)
  • NOT be sent to Target 3 (different rewrite configuration - strips to /users)

​
Priority Calculation

When using path rewriting, request priority is automatically calculated to ensure proper routing order:
  • Base priority: 100
  • Path matching adds +10 to priority
  • Exact match adds +5 more
  • Prefix match adds +3 more
  • Regex match adds +2 more
  • Root path / gets priority 1 (lowest, acts as catch-all)
  • Custom priorities override the automatic calculation
⌘I