FAQ
Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform

English

Türkçe

English

Türkçe

Appearance

Basic

The change I made does not seem to take effect; what should I check? ​

Short answer

A change saved in TR7 is applied automatically within about one second; Reload is not required (When does a change I make take effect; does it go live as soon as I save it?). If the effect is not seen, it is first checked from the Used in tab that the change was really made on the object this vService uses, and from the Details tab that there is no Modifying vService, Internal sync error or configuration error message in the vService preview. Then it is examined whether the request reaches the condition of the change (condition, action order, Conditional Backend Services block), whether the response comes from the TR7 cache or the browser cache, and whether Persistence keeps the user on the old server. In a cluster, if Manual Sync Mode is on, the change has not gone to the peer device; it is sent with Synchronize.

Problem: The Saved Change Does Not Appear in Traffic ​

A profile, action or Backend Service setting was changed and saved, but the behavior did not change on the client side. It must be determined whether the change was not applied, whether the request never reaches the change, or whether the old response comes from a cache or an old connection.

Causes and Solutions ​

CauseHow to recognize itSolution
The changed object is not used in the vServiceThe vService is not in the Used in tab of the objectThe correct object is edited, or the object is assigned to the vService
Applying the change is in progressThe vService status is Evaluating; Modifying vService in DetailsA short wait
The change could not be appliedInternal sync error — please notify the TR7 technical team in Details; traffic continues with the previous configurationSupport is requested (How do I download the encrypted diagnostic bundle for the support team (Encrypted Support Bundle)?)
Configuration errorconfiguration error(s) summary in DetailsWhat does the configuration error(s) warning in the vService preview (DNS Resolution Error, Port binding error) mean; where does Port Collision appear?
The feature does not work on this vServiceThe selected core engine does not support: …, Running without …: not covered by the license or Keep header names is active on this vService in DetailsThe Core Engine, the license or the Keep Header Names setting is reviewed
The condition does not match, or an action above terminates the requestThe action's Hit counter does not increaseThe condition or the order is corrected (Why is my Action not triggering?)
The response comes from the TR7 cacheTRCACHE: HIT in the responseThe cache is emptied (Old content is still being served after an application update; what should I do?)
The response comes from the browser cacheNo header; new behavior in a private windowThe browser cache is cleared; permanent 301 redirects and HSTS are stored in the browser
Persistence keeps the user on the old serverThe same user always goes to the same serverIt is tried with a new session (Persistence is enabled, but my users still end up on different servers; why?)
The cluster is not synchronizedManual Sync Mode is on; Sync. Summary is not equalSynchronize is used (Is the configuration automatically synchronized between cluster members?)
The Backend Service address is a domain name (FQDN)The Backend Service goes to the old IPThe name is resolved when the configuration is loaded (Can I enter a domain name (FQDN) instead of an IP as the Backend Service address?)

Where Is It Monitored? ​

ScreenPathWhat it shows
Sync indicatorBottom right of the screenThe progress of applying the change (Syncing …); All synced when it finishes (When does a change I make take effect; does it go live as soon as I save it?)
DetailsLoad Balancer vServices → vService → right panelApplication status, configuration errors and feature warnings
LogIn the same panelWho saved the change and when
Action HitsvService → Dashboard → Action Hits tabHow many times the actions with Hit counter on were triggered
Sync SummaryHA Clustering & SyncSynchronization status in the cluster

Solution: Three Methods ​

The three methods are applied in order: first it is checked that the change was applied, then that the request reaches the change, and finally the source of the old response.

Your situationSuitable method
Whether the change was appliedMethod 1: Used in and Details
Whether the request reaches the changeMethod 2: Condition, order and Hit counter
Where the old response comes fromMethod 3: Cache, Persistence and cluster
  • How it works The change is applied only to the vServices that use the object; problems that occur during or after the application appear in the Details tab of the vService.
  • Where it is opened The object's preview → Used in · Load Balancer vServices → vService → Details
  • Requirement No additional setting is required.
  • vService type HTTP · L7 TCP · Network

Step-by-Step Configuration ​

1
Adım 1 Open the Used in tab of the object

The changed profile, action, condition or Backend Service is selected in its own list; the Used in tab is opened in the preview on the right, and it is verified that the vService is in the list (When I change a condition or an action, which vServices are affected?, How do I see which vServices use a Backend Service ("Used in")?). If the tab is not there, the object is not used anywhere.

2
Adım 2 Select the vService

In the Left Monitor Panel, the vService is selected from the Load Balancer vServices list; the Details tab is opened in the right panel.

3
Adım 3 Read the messages

The Status Logs tab in the same panel shows the recent status transitions, and the Log tab shows who made the save and when.

Verification ​

1DetailsTR7 side

The Details tab and the sync indicator at the bottom right are checked.

ExpectedStrip green (OK), no warning, indicator All synced

Method 2: Condition, Order and Hit Counter ​

  • How it works An action or conditional routing is applied only if the condition matches and an action that ran earlier does not terminate the request; the action's Hit Counter shows the match.
  • Where it is opened Action form → Hit Counter · vService → Dashboard → Action Hits tab
  • Requirement No additional setting is required.
  • vService type HTTP · L7 TCP

Step-by-Step Configuration ​

1
Adım 1 Open the edit form of the action

On the Load Balancer → Actions screen, the action is selected and the Edit button is clicked.

2
Adım 2 Turn on Hit counter

The Hit Counter switch is turned on (Can I see how many times an action has been triggered (hit counter, Action Hits)?).

3
Adım 3 Save

The Edit button at the bottom of the form is clicked, and the request is sent again.

Verification ​

1CounterTR7 side

After the request is sent, the Action Hits tab of the vService dashboard is checked.

ExpectedThe action's counter increases
If the counter does not increase, the condition does not match or an action higher up terminates the request: it is checked that the action is in the Actions field of the vService, its position in the list, and whether it runs in the request or the response stage (Why is my Action not triggering?, If an action blocks or redirects traffic, do the subsequent actions run?). For a routing change, the Conditional Backend Services block the request falls into is checked (How do I change the evaluation order of Conditional Backend Services blocks?).

Method 3: Cache, Persistence and Cluster ​

  • How it works The old response may come from the TR7 cache, from the browser, from the old server because of Persistence, from an old connection that remains open, or from a peer device that is not synchronized.
  • Where it is opened Client · Settings → Device Management → HA Clustering & Sync
  • Requirement No additional setting is required.
  • vService type HTTP · L7 TCP · Network

Step-by-Step Configuration ​

1
Adım 1 Isolate the cache

curl -I https://www.example.com/ is run from the client. If the response has the TRCACHE: HIT header, the response is from the TR7 cache (How do I know a response came from the cache (Cached(HIT) Header Name, default value TRCACHE)?); the cache is emptied by Reloading the vService or by saving a change in the Cache profile (Old content is still being served after an application update; what should I do?). If there is no header, a private window is used for the browser cache; permanent 301 redirects and HSTS are stored in the browser.

2
Adım 2 Isolate Persistence and open connections

With cookie-based persistence, a Weight or algorithm change does not move the existing persistent sessions; with Hash persistence, however, the mapping table is reset on every reload and users are redistributed. The result is tried with a new client or session (Does saving a configuration change reset the persistence tables?). In long-lived connections such as WebSocket and L7 TCP, the new setting is seen on a new connection.

3
Adım 3 Check the cluster synchronization

On the Settings → Device Management → HA Clustering & Sync screen, it is checked on the Cluster Status row whether Manual Sync Mode is on, and the Sync. Summary status is checked (Sync Summary). With the default automatic synchronization, the change is transferred to the peer device immediately; if Manual Sync Mode is on, the change stays on the local device. If traffic goes to the peer device through the VIP (What is the Master/Slave role on a VIP?), the change is not seen in this case.

4
Adım 4 Send with Synchronize

If Manual Sync Mode is on, the Synchronize button is clicked on the device where the change was made, and the confirmation is given (Is the configuration automatically synchronized between cluster members?).

Verification ​

1ResponseClient side

The request is repeated from a private window and with a new session.

ExpectedThe new behavior is seen
2ClusterTR7 side

The Sync. summary row on the HA Clustering & Sync screen is checked.

ExpectedSynced

Common Mistakes ​

  • Doing a Reload after every change. A saved change is applied automatically; Reload restarts the vService and is not required for ordinary changes (What does Reload in the right-click menu do; how is it different from Disable / Enable?).
  • Editing another profile without checking Used in. Profiles with similar names can be confused.
  • Concluding that the change was not applied without separating the browser cache from the TR7 cache. The TRCACHE header shows the source.
  • Testing with the same user and overlooking Persistence. A persistent session keeps the user on the old server.
  • Forgetting the peer device while Manual sync mode is on in a cluster. The change is valid only on the local device until it is sent with Synchronize.
  • Asking for support without collecting information if the problem persists. What to add to the support ticket: Which information should I collect before contacting TR7 support?

How it is done in the documentation

Related questions