Java 8 ha raggiunto la fine del supporto
e verrà ritirato
il 31 gennaio 2026. Dopo il ritiro, non potrai eseguire il deployment di applicazioni Java 8, anche se la tua organizzazione ha utilizzato in precedenza un criterio dell'organizzazione per riattivare i deployment di runtime legacy. Le tue applicazioni Java 8 esistenti continueranno a essere eseguite e a ricevere traffico dopo la
data di ritiro. Ti consigliamo di eseguire la migrazione all'ultima versione supportata di Java.
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Un firewall determina quale traffico di rete è consentito e quale viene rifiutato. I firewall possono essere applicati al traffico in entrata, in uscita o a entrambi. Per App Engine, il firewall App Engine si applica solo
al traffico in entrata indirizzato alla tua app o al tuo servizio.
Panoramica
Il firewall di App Engine viene controllato per tutti i tipi di
richieste alla tua app, tra cui:
Traffico web normale indirizzato all'indirizzo appspot.com dell'app o al dominio personalizzato.
Traffico da origini interne come macchine virtuali (VM) Compute Engine e Cloud Tasks.
Nei casi in cui la tua app è configurata per utilizzare altri servizi o prodotti di rete, potresti dover creare regole per controllare il traffico in entrata sia nel firewall di App Engine sia nelle impostazioni di sicurezza o del firewall di altri prodotti. Questa guida illustra il comportamento generale del firewall App Engine
e i dettagli relativi a questi casi d'uso speciali.
Regole firewall di App Engine
Puoi configurare le regole firewall di App Engine
utilizzando la console Google Cloud , Google Cloud CLI o l'API Admin
specificando regole che consentono o bloccano intervalli IP specifici.
Per impostazione predefinita, a qualsiasi richiesta che non corrisponde a una regola viene consentito l'accesso alla tua
app. Se devi bloccare tutte le richieste che non corrispondono a una regola specifica
(escluse le richieste dei servizi interni consentite per impostazione predefinita), modifica l'azione della regola
default in deny.
Funzionalità del firewall
Nell'ambiente standard di App Engine, il firewall di App Engine può consentire a determinati
traffici interni di bypassare il firewall. Ciò significa che se imposti la regola default su
deny, le richieste di determinati servizi destinate all'ambiente standard di App Engine non
vengono bloccate. Si tratta di tutti i tipi di traffico richiesti nella configurazione dell'app o inviati dalla stessa app. Le richieste che aggirano le regole firewall in questo modo includono:
Per le app che utilizzano l'ambiente standard di App Engine e i servizi inclusi nei runtime di prima generazione, anche le notifiche della precedente API Mail bypassano il firewall.
Consentire le richieste in entrata dai tuoi servizi
La tabella seguente elenca gli intervalli IP e il comportamento del firewall di App Engine per
i servizi comuni. L'intervallo IP che utilizzi dipende dal fatto che le richieste in entrata
vengano inviate a una versione eseguita nell'ambiente standard di App Engine o
nell'ambiente flessibile.
Servizio
Intervallo IP per le richieste inviate all'ambiente standard di App Engine
Intervallo IP per le richieste inviate all'ambiente flessibile di App Engine
Cloud Storage o Blobstore
0.1.0.30/32
Non applicabile
Job Cloud Scheduler che utilizzano attività HTTP di App Engine e App Engine in Cloud Tasks (incluse le code delle attività App Engine)
0.1.0.2/32, ignora la regola firewall predefinita se impostata su rifiuta
0.1.0.2/32
Cron di App Engine
0.1.0.1/32 o 0.1.0.2/32, ignora la regola firewall predefinita se impostata su rifiuta
A seconda del tuo caso d'uso, queste istruzioni aggiuntive potrebbero essere applicate durante la configurazione delle regole firewall di App Engine:
Le richieste dei cron job di App Engine appena creati o aggiornati inviate all'ambiente standard o flessibile di App Engine provengono da 0.1.0.2. Per i cron job creati con versioni precedenti di gcloud (precedenti alla 326.0.0), le richieste cron provengono da 0.1.0.1. Per scoprire di più su come identificare le richieste del servizio Cron di App Engine, consulta Convalida delle richieste cron.
L'app in esecuzione nell'ambiente standard ha due servizi: frontend_service
e backend_service. frontend_service utilizza Cloud Tasks con
App Engine HTTP per inviare messaggi a backend_service. Poiché la regola firewall default consente le richieste Cloud Tasks anche se configurata per deny, non è necessario creare una regola firewall per Cloud Tasks.
Tuttavia, se volessi limitare l'accesso alla tua app e bloccare esplicitamente le richieste di Cloud Tasks, dovresti creare una regola firewall deny per l'intervallo IP 0.1.0.2/32.
Esempio di ambiente flessibile di App Engine
La tua app in esecuzione nell'ambiente flessibile ha due servizi:
frontend_service e backend_service e ha un firewall configurato per negare
il traffico per impostazione predefinita. frontend_service utilizza Cloud Tasks con
App Engine HTTP per inviare messaggi a backend_service. Poiché la regola firewall default
nega le richieste Cloud Tasks, devi creare una regola firewall
allow per 0.1.0.2/32.
Il bilanciatore del carico non interferisce né interagisce con le regole firewall di App Engine. Le regole firewall di App Engine non vengono valutate finché un NEG serverless non indirizza il traffico ad App Engine.
Ti consigliamo di utilizzare i controlli di ingresso
in modo che la tua app riceva solo le richieste inviate dal bilanciamento del carico
(e dal VPC, se lo utilizzi). In caso contrario, gli utenti possono utilizzare l'URL App Engine della tua app per bypassare il bilanciatore del carico, i criteri di sicurezza di Cloud Armor, i certificati SSL e le chiavi private che vengono passati tramite il bilanciatore del carico.
Impedire l'accesso ai contenuti memorizzati nella cache
Il firewall di App Engine si trova dietro i meccanismi che memorizzano nella cache i contenuti, ad esempio
proxy web e browser. Quando i contenuti vengono memorizzati nella cache, vengono pubblicati
pubblicamente dall'URL specifico fino alla scadenza e sono accessibili anche dopo
la creazione di nuove regole firewall.
Per informazioni sulla modifica del tempo di scadenza predefinito per i contenuti statici
o per impedire la memorizzazione nella cache dei contenuti statici, consulta
Scadenza della cache.
Per impedire la memorizzazione nella cache dell'output dei contenuti dinamici dal codice della tua app, utilizza
le intestazioni della risposta HTTP Cache-Control e Expires. Per saperne di più su
queste intestazioni HTTP, incluso come controllare la memorizzazione nella cache, vedi
Evitare la memorizzazione nella cache.
Passaggi successivi
Segui le istruzioni riportate in Creazione di
firewall per
scoprire come configurare le regole firewall di App Engine.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eThe App Engine firewall controls incoming network traffic to your app, allowing or denying requests based on specified IP ranges and rules.\u003c/p\u003e\n"],["\u003cp\u003eBy default, the App Engine firewall allows any request that doesn't match a rule, but this can be changed to deny all unmatched requests.\u003c/p\u003e\n"],["\u003cp\u003eCertain internal traffic, such as warmup requests and requests from Cloud Scheduler or Cloud Tasks, can bypass the default firewall rule even if it's set to deny.\u003c/p\u003e\n"],["\u003cp\u003eServices like Cloud Storage, Cloud Scheduler, and URL Fetch have specific IP ranges for requests sent to App Engine environments, which can be used to create more specified firewall rules.\u003c/p\u003e\n"],["\u003cp\u003eWhen using Cloud Load Balancing with App Engine, it is recommended to use ingress controls and keep the default App Engine firewall rule as allow, instead of deny, while using Cloud Armor WAF rules.\u003c/p\u003e\n"]]],[],null,["# Understanding the App Engine firewall\n\nA **firewall** determines which network traffic is allowed to pass and which\ntraffic is rejected. Firewalls can apply to incoming traffic (ingress), outgoing\ntraffic (egress), or both. For App Engine, the App Engine firewall only\napplies to incoming traffic routed to your app or service.\n\nOverview\n--------\n\nThe App Engine firewall is checked for all types of\nrequests to your app, including:\n\n- Regular web traffic routed to the app's `appspot.com` address or custom domain.\n- Requests that arrive from [Cloud Load Balancing](/load-balancing).\n- Traffic from internal sources such as Compute Engine virtual machines (VMs) and Cloud Tasks.\n\nIn cases where your app is configured to use other networking services or\nproducts, you might need to create rules for controlling incoming traffic in\nboth the App Engine firewall and the firewall or security settings of other\nproducts. This guide covers the general behavior of the App Engine firewall,\nand details about those special use cases.\n\nApp Engine firewall rules\n-------------------------\n\nYou can [configure App Engine firewall rules](/appengine/docs/legacy/standard/java/creating-firewalls)\nusing the Google Cloud console, the Google Cloud CLI, or the Admin\nAPI by specifying rules that allow or block specified IP ranges.\n\nBy default, any request that does not match a rule is allowed access to your\napp. If you need to block all requests that do not match a specific rule\n(excluding requests from internal services allowed by default), change the\n`default` rule's action to `deny`.\n\n### Firewall feature\n\nIn the App Engine standard environment, the App Engine firewall can allow certain internal\ntraffic to bypass the firewall. This means that if you set the `default` rule to\n`deny`, requests from certain services destined for the App Engine standard environment do not\nget blocked. These are all types of traffic requested in the app's own\nconfiguration, or sent from the same app. Requests that bypass firewall rules in\nthis way include:\n\n- [Warmup requests](/appengine/docs/legacy/standard/java/configuring-warmup-requests)\n- Cloud Scheduler jobs using [App Engine HTTP](/scheduler/docs/creating#creating_jobs) (including [App Engine Cron](/appengine/docs/legacy/standard/java/config/cron)\n\n \u003cbr /\u003e\n\n - [App Engine tasks in Cloud Tasks](/tasks/docs/creating-appengine-tasks) (including App Engine Task Queues)\n\n For apps that use the App Engine standard environment and services bundled with the [first\n generation runtimes](/appengine/docs/standard/runtimes), notifications from the\n legacy Mail API also bypass the firewall.\n\n Allowing incoming requests from your services\n ---------------------------------------------\n\n The following table lists the IP ranges and App Engine firewall behavior for\n common services. The IP range you use depends on whether the incoming requests\n are delivered to a version that runs on the App Engine standard environment or\n flexible environment.\n\n Depending on your use case, these additional instructions might apply when\n configuring App Engine firewall rules:\n - Requests from newly created or updated App Engine Cron jobs sent to either the App Engine standard or flexible environment come from `0.1.0.2`. For Cron jobs created with older gcloud versions (earlier than 326.0.0), Cron requests will come from `0.1.0.1`. To learn more about how to identify requests from the App Engine Cron service, see [Validating cron requests](/appengine/docs/legacy/standard/java/scheduling-jobs-with-cron-yaml#validating_cron_requests).\n - If your app interacts with Cloud Load Balancing or is connected to a VPC network, see the [Interaction with other products or services](#interaction_with_other_products_or_services) section below.\n\n | **Caution:** Creating a rule for IP `0.0.0.0` will apply to **all** Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from `0.1.0.40` will allow **any** App Engine app to make URL Fetch requests to your app.\n\n ### App Engine standard example\n\n Your app running in the standard environment has two services: `frontend_service`\n and `backend_service`. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule allows Cloud Tasks requests even if configured to `deny`, you do not need to create\n a firewall rule for Cloud Tasks.\n\n However, if you wanted to restrict access to your app and explicitly block\n Cloud Tasks requests, you would create a `deny` firewall rule for IP range `0.1.0.2/32`.\n\n ### App Engine flexible example\n\n Your app running in the flexible environment has two services:\n `frontend_service` and `backend_service`, and has a firewall configured to deny\n traffic by default. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule denies Cloud Tasks requests, you would need to create an\n `allow` firewall rule for `0.1.0.2/32`.\n\n Interaction with other products or services\n -------------------------------------------\n\n ### Cloud Load Balancing\n\n If you use [Cloud Load Balancing and serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts), note the following:\n - The load balancer does not interfere or interact with App Engine firewall rules. The App Engine firewall rules are not evaluated until a serverless NEG directs traffic to App Engine.\n\n \u003c!-- --\u003e\n\n - We recommend that you [use ingress controls](/appengine/docs/standard/application-security#ingress_controls)\n so that your app only receives requests sent from the load balancer\n (and the VPC if you use it). Otherwise, users can use your app's\n App Engine URL to bypass the load balancer, Cloud Armor\n security policies, SSL certificates, and private keys that are passed through\n the load balancer.\n\n - If your [ingress controls](/appengine/docs/legacy/standard/java/application-security#ingress_controls) are set to receive `internal-and-cloud-load-balancing` traffic, leave the default App Engine firewall rule as is (`allow`), and use [Google Cloud Armor web application firewall (WAF) rules](/armor/docs/rule-tuning).\n\n Preventing access to cached content\n -----------------------------------\n\n The App Engine firewall sits behind mechanisms that cache content, for example\n web proxies and browsers. When content is cached, that content is served\n publicly from the specific URL until it expires and can be accessed even after\n creating new firewall rules.\n For information about changing the default expiration time for static content or preventing static content from being cached, see [Cache expiration](/appengine/docs/legacy/standard/java/how-requests-are-handled#static_cache_expiration).\n\n \u003cbr /\u003e\n\n To prevent dynamic content output from your app's code from being cached, use\n the `Cache-Control` and `Expires` HTTP response headers. For more information about\n these HTTP headers, including how to control caching, see\n [Avoiding caching](https://wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching).\n\n\n What's next\n -----------\n\n Follow the instructions in [Creating\n Firewalls](/appengine/docs/legacy/standard/java/creating-firewalls) to\n learn how to configure App Engine firewall rules."]]
